Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht 🙂
Schlagwort: Key
Ich habe nach längerem dann mal meinen KSK für´s dnssec getauscht. Bzw. ich bin gerade dabei 🙂
Der alte war noch ein 1024bit NSEC3RSASHA1. Jetzt ist auch klar warum er getauscht werden musste 😛 Der neue ist nun ein NSEC3RSASHA1 mit 4096bit. Als zweiten neuen Key habe ich einen RSASHA512 mit ebenfalls 4096bit erstellt. So habe ich für den Fall der Fälle auch direkt einen ohne SHA1 im „Anschlag“.
Dieser neue Key ersetzt in Kürze den alten 1024bit KSK Schlüssel. Bereits jetzt sollte es aber für jeden nur noch über den 4096bit NSEC3RSASHA1 Schlüssel laufen.
Inzwischen sollte wohl jede halbwegs aktuelle Software mit dnssec Support mit diesen Schlüsseln umgehen können. Wenn nicht, wird es Zeit für ein Update 😀
In diesem Sinne!
* U-P-D-A-T-E *
Inzwischen ist auch der andere Schlüssel oben und sollte sich so langsam durch die Welt sprechen….
http://dnsviz.net/d/kernel-error.de/dnssec/
OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt — ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.
Client konfigurieren
Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:
VerifyHostKeyDNS yes
Oder nur für die aktuelle Sitzung:
ssh -o "VerifyHostKeyDNS=yes" server.example.de
SSHFP-Records erzeugen
Am einfachsten direkt auf dem Server mit ssh-keygen — das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:
ssh-keygen -r server.example.de.
Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):
server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148 server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3... server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62 server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1... server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6... server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...
Aufbau des SSHFP-Records
Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:
hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]
Algorithmus:
- 1 — RSA
- 3 — ECDSA
- 4 — Ed25519 (empfohlen, ab OpenSSH 6.7)
DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.
Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden — ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.
Prüfen
Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:
dig +short server.example.de SSHFP 1 1 47890EECC9A2893061734B07B8F60CAA1A856148 1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3... 3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62 4 2 D4E5F6A7B8C9...
Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein — sonst ist die Antwort nicht vertrauenswürdig:
dig +dnssec server.example.de SSHFP | grep flags ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
Verbindungsaufbau mit SSHFP
Ohne SSHFP-Records im DNS meldet OpenSSH:
DNS lookup error: data does not exist No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
Mit SSHFP-Records und DNSSEC:
debug1: found 4 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS
secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure — der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.
Strenge Prüfung erzwingen
Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:
Host *
VerifyHostKeyDNS yes
StrictHostKeyChecking yes
Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung — setzt aber voraus, dass alle Zielserver SSHFP-Records haben.
Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.