OpenSSH bietet die Möglichkeit die Fingerprints der Host Keys in einer DNS Zone als SSHFP-RECORD zu speichern. Dieses ermöglicht bei einem Verbindungsaufbau, die Fingerprints gegenn welche in der DNS Zone zu validieren. Es kann daher helfen, sich z.B. gegen man in the middle Angriffe zu schützen. Ist die Zone zusätzlich noch per DNSSEC (http://www.kernel-error.de/dnssec) geschützt, hat man schon eine recht hohe Sicherheit gegen solche Angriffe. Dieses zielt hauptsächlich darauf ab, Zugriffe per Kennwort zu sichern. Basiert das Login auf SSH Schlüssel, kann ein Angreifer im seltensten Fall etwas mit den Daten anfangen, dennoch hilft jedes Stückchen mehr Sicherheit! OK, es steht und fällt alles wieder beim Thema DNS, daher bitte auf DNSSEC achten.
Damit SSH auch prüft ob es im DNS einen passenden RECORD gibt muss folgendes in die Konfigurationsdatei /etc/ssh/ssh_config eingetragen werden, sofern man es global für alle Benutzer auf seinem Client aktivieren möchte:
$ echo "VerifyHostKeyDNS yes" >> /etc/ssh/ssh_config
Soll es für die eigene Benutzerumgebung geschehen liegt diese Konfigurationsdatei natürlich unter: ~/.ssh/ssh_config Soll es nur für die aktuelle Sitzung aktiviert werden, lässt es sich als Option einfach mitgeben:
$ ssh -o "VerifyHostKeyDNS=yes" www.kernel-error.de
Baut man nun eine Verbindung auf, fragt OpenSSH den DNS Server ob dieser Informationen zum erwarteten Fingerprint liefern kann. Sind keine Einträge in der DNS Zone vorhanden schaut der Verbindungsaufbau wie folgt aus:
$ ssh -v www.kernel-error.de
OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010
.....
DNS lookup error: data does not exist
The authenticity of host 'www.kernel-error.de (2001:7d8:8001:100::dead:beef)' can't be established.
RSA key fingerprint is fc:aa:73:17:bc:6a:0a:4f:af:3a:98:9e:73:b8:c4:68.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Um dieses zu „verbessern“, gibt mehrere Möglichkeiten die SSHFP RR für seine Zone zu erstellen. Es gibt das Programm sshfp…
$ sshfp www.kernel-error.de
www.kernel-error.de IN SSHFP 1 1 f9dfcb6311e31da8c267ae53a5830887bd2bb3b3
www.kernel-error.de IN SSHFP 2 1 97179afabaaf9b68b05dbf1357cffe3de6ce76fe
Dann gibt es unter anderem noch die, von mir präferierte Lösung, direkt per ssh-keygen auf dem Zielhost (Server):
$ ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -r www.kernel-error.de.
www.kernel-error.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
www.kernel-error.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e33dae0a29c46226e9ff691cd2
$ ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -r www.kernel-error.de.
www.kernel-error.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
www.kernel-error.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1cd2b73cca532a8111c9515b4
Dabei ist der SSHFP-RECORD wie folgt aufgebaut:
Zielhost ==> Protrokollart ==> RR-Typ ==> Host-Key Algorithmus ==> Hash-Art des FP ==> Fingerprint
Folgende Host-Key-Algorithmen sind bisher definiert:
- 1 ssh-rsa
- 2 ssh-dss
- 3 ecdsa
- 4 ed25519
Hash-Arten des FP sind dabei SHA1 und SHA2(56). 1 wäre dabei SHA1 und 2 logischerweise SHA2
Diese fertigen RECORDS kann man nun in seiner DNS-Zone veröffentlichen, dass die Zone zum Host zu passen hat, muss ich ja sicher nicht mehr erwähnen, oder?
Baut man nun die Verbindung erneut auf, findet OpenSSH auch etwas.
$ ssh -v www.kernel-error.de
OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010
.....
debug1: found 2 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'www.kernel-error.de (2001:7d8:8001:100::dead:beef)' can't be established.
RSA key fingerprint is fc:aa:73:17:bc:6a:0a:4f:af:3a:98:9e:73:b8:c4:68.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Natürlich lassen sich die Einträge auch mit dig abrufen:
$ dig +short www.kernel-error.de IN SSHFP
3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62
3 2 E1C76BD66B5A0641789B0B37BE5B80AE3F6395C1CD2B73CCA532A811 1C9515B4
1 1 47890EECC9A2893061734B07B8F60CAA1A856148
1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E33DAE0A29C46226E9 FF691CD2
SSHFP 7 3 86400 20160307114536 20150313114536 13952 kernel-error.de. hib4uoiPCBlAXytsVHsqvGdGDRPdec42nA2J7IW8mQVV/o7fb5kPfV6J ZIp4D6O0RsSWW++9QzvCd0gHiTQcQLXdpypCoSBbLYGpWnBl3zCk9zFS iLhawl79VFun7xccZU9UjWoHRyrEo5pDfN3heBgT4ycjlB2m0i40D5WQ 25pCh95yAnSB/wchW4MwffDgc+10GrRcpxWL662k6pFRpLFHsDZ2YS6c zYEK2u1nAc0hI0XqtJrXxDxZZ9reHWvmk5wAK3LHcoWOv5DFP6LyIzY8 omhm+zF9KzIt8V0PuzMD9rUfeZAZjjCsllxv39bx+UHcS0ZsKxpCV4Ny c2OSCOCyHjtc1+qgYuZlkL5rej7wOVvCTB5Jym4B0vTO7ct22/VoqEdh zLjiWXSDW87qkNnImGU1EXHMqOXU5qzxgKgRjMu6AfJYB+zRP2B2P5eJ I9sGWOWJIV24ot1dWisWeSvItXNHW84mzFVgqUUuMKZ5uQGocpWjMc7c b0h0o4P4D0HtarBuRV7Z6QsJjEy0zMst2PChi3y+WFP4ar7Tl59K3ePN 7Qw/695jjA2YitpUYWBZL052r5d2u9hBTZGPvxvJRjFfvNcdy7Sv3ii1 sl6dTp/XIlJ82xsVEwNEYqgSQVJwNEzIcH+doUF4pGKnFmOWG/NlXfYJ 9Kx2Xon6c7Y=
SSHFP 10 3 86400 20160307114536 20150313114536 12698 kernel-error.de. dbv2KMbxb4Vd+kLz86hGjdc12b3/8THtIfThd8kjm5ik9Yxo3njcw60/ sJ9wvJ4/2AiBNoEebh3wUxnoJprqsjyEdIq+7mPggVhs6VV5Sl9GZoNM 1bzkq85xjHt9/KVzLwou9/s0t9PgZ3vl2wU6MMl5MvleGumw+w6DnZpz NXzX57IpMs3TCMHPVhpYglGjtRcDPnfFSqbLLwnM5rbidp80iEob/d3J Xm6lSPBuwrry4aAYErWMxxsDJBosXKGC2EQNKK5PrkVF9JbWwXUFXowU H9m1iNsDaRBP6xqKoa+I4efR9GNojb55s2Nh1b6T+9zVyjcclp2rYbt/ QL6l6GSTHvoP6L7o3H3heg1Q4uUu+mj7a8lEHfuF2jbp6afjrL17hR/b v7ArzP7PpV6KOmx15pBLH3V0GoEle7WKon65+6mNaDDvs5yh7LSd1Im3 zAi1C0TUkf4VN4MU+FhDh+r6KKsqh0WvP0hc7UaTcpEIH3ox7QbHGvf7 zxiBypRVfrrW3OQhQvRk6U4wIIx1XicaYRfkPmEL/OtYTc9B81dGe3ci JLZLedMCWifPtsO+B3ml5apH8+MTu7fyWEpf4NPz2egWzFkHYsl8Out8 2z7jzhPwgAfyZ2qr0z1SZWSpxvZ/P7LqNaauoFQxpyZT6/qFXA8M1quf Tornope2Y4E=
Wie immer bei DNSSEC zur Sicherheit prüfen ob die Antwort „sauber“ ist:
$ dig +dnssec www.kernel-error.de IN SSHFP |grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; MBZ: 7e06 , udp: 512
In der Antwort muss das ad flag gesetzt sein!!!
Nach all dieser Arbeit könnte man nun noch OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host-Key erfolgreich validiert werden konnte. Dieses wieder, wie oben beschrieben, in der /etc/ssh/ssh_config oder den anderen Stellen:
Host *
StrictHostKeyChecking yes
Ich mag solche Dinge sehr 🙂 Sehr kleiner Aufwand und schon ist es um einiges sicherer…
Kleines Update 16.02.2015
ed25519 erst richtig ab OpenSSH Version 6.7, ecdsa fragwürdig sicher und dss bitte NICHT! Ich will sagen >= OpenSSH 6.6 4096bit RSA bitte 🙂
Der Verbindungsaufbau sieht in der aktuellen OpenSSH Version etwas anders aus. Erfolgreich sollte es so aussehen:
debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
Inzwischen arbeitet OpenSSH direkt mit DNSSEC, wenn möglich. Solltet ihr also der Meinung sein, Fingerprints und Zone korrekt konfiguriert zu haben, OpenSSH wird aber einfach nicht „glücklich“… Dann prüft doch mal bitte auf Extension mechanisms for DNS (http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS)! Aktiviert sich normalerweise mit folgender Zeile in der /etc/resolv.conf
options edns0