Das Konfigurieren von SSH-Fingerabdrücken auf DNS als Ersatz für bekannte_Hosts schlägt fehl

Die SSHFP-Datensätze wurden wie folgt auf dem SSH-Server generiert und dann der Zone in bind hinzugefügt:

$ ssh-keygen -r www.test.us.
www.test.us. IN SSHFP 1 1 ad04dfaf343a93beeb939eed1612168f7eadbed7
www.test.us. IN SSHFP 2 1 432209c72c4f0e99546d601dd96c04ce804191f9

Die erforderlichen Einträge können wie gezeigt über DNS vom SSH-Client abgerufen werden:

$ dig www.test.us any
;; QUESTION SECTION:
;www.test.us.           IN  ANY

;; ANSWER SECTION:
www.test.us.        120 IN  SSHFP   1 1 AD04DFAF343A93BEEB939EED1612168F7EADBED7
www.test.us.        120 IN  SSHFP   2 1 432209C72C4F0E99546D601DD96C04CE804191F9
www.test.us.        120 IN  A   192.168.1.50

Ssh auf dem Client findet sie jedoch nicht, wenn eine Verbindung hergestellt wird:

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes www
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/test/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to www [192.168.1.50] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11
debug1: match: OpenSSH_5.8p2_hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c
DNS lookup error: name does not exist
The authenticity of host 'www (192.168.1.50)' can't be established.
RSA key fingerprint is 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Irgendwelche Ideen, warum dies fehlschlägt? Ich weiß, dass DNSSEC erforderlich ist, um die Sicherheit zu gewährleisten, und dass ich eine Warnung erhalten sollte, da DNSSEC derzeit nicht aktiviert ist. Ich hoffe, dass dies zuerst ohne DNSSEC funktioniert, bevor ich anfange, dies als zusätzliches Problem anzugehen.

Der SSH-Server ist FreeBSD 9.1 mit OpenSSH_5.8p2_hpn13v11 und hostet auch DNS mit BIND 9.8.3-P4. Ich habe versucht, eine Verbindung von OS X 10.8.2 mit OpenSSH_5.9p1 sowie von Arch Linux 3.6.10-1-ARCH mit OpenSSH_6.1p1 herzustellen.

Aktualisieren

In einem weiteren Versuch, dieses Problem zu beheben, stellte ich eine neue OpenBSD 5.2-VM auf, in die OpenSSH_6.1 als SSH-Server integriert ist. Da alle anderen Implementierungen des OpenSSH-Servers nur Ports des OpenBSD-Servers sind, sollte dies sicherlich funktionieren. Auf dem Server generiere ich die SSHFP-Einträge:

# ssh-keygen -r vm1.test.us.  
vm1.test.us. IN SSHFP 1 1 419c5338920e11183380d81f002fc998389b944f
vm1.test.us. IN SSHFP 1 2 cb5bbbf5aef231f57a1a4dcf1e790f1be032b124d0d591023f33cfd5f91ec556
vm1.test.us. IN SSHFP 2 1 0fdf92ce946b5cfee5f96a3e1ef710edc50280ff
vm1.test.us. IN SSHFP 2 2 f2ee7334ee9f9a426f51f20af8f4bc7155d567c9d38a6bffaa6c643af405711e
vm1.test.us. IN SSHFP 3 1 b5e94320f0bc0b46cc6627ca7221679a65c79962
vm1.test.us. IN SSHFP 3 2 60704213a0bbd8dae813d113bfe4ae190a780b89836e6e1c567b7cfde89805f8

Ich füge sie dem FreeBSD-Bindungsserver hinzu und lade den Namen neu. Testen Sie dann, ob ich auf die Datensätze zugreifen kann:

$ host -t any vm1
vm1.test.us has SSHFP record 1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us has SSHFP record 1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us has SSHFP record 2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us has SSHFP record 2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us has SSHFP record 3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us has SSHFP record 3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us has address 192.168.1.60


$ dig -t any vm1.test.us
;; QUESTION SECTION:
;vm1.test.us.           IN  ANY

;; ANSWER SECTION:
vm1.test.us.        120 IN  SSHFP   1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us.        120 IN  SSHFP   2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us.        120 IN  SSHFP   2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us.        120 IN  SSHFP   3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us.        120 IN  SSHFP   3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us.        120 IN  SSHFP   1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us.        120 IN  A   192.168.1.60

Die Einträge werden eindeutig über DNS bereitgestellt, daher versuche ich, ssh zu verwenden:

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes root@vm1
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to vm1 [192.168.1.60] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f
DNS lookup error: name does not exist
The authenticity of host 'vm1 (192.168.1.60)' can't be established.
RSA key fingerprint is d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? 

An diesem Punkt denke ich, dass es sicher ist, die SSH-Clients und -Server als Fehlerquelle zu eliminieren. Stattdessen werde ich den DNS-Server fokussieren. Wenn jemand keinen Vorschlag hat, wo er suchen soll, muss ich wohl keine Paketerfassungen machen und sie durchsuchen, um Hinweise zu finden.

Update2

Okay, hier sind die Ergebnisse meiner Paketerfassungen. ssh www; schlägt mit dem Standard fehl

No matching host key fingerprint found in DNS.

und die Paketerfassung zeigt, dass DNS keinen Eintrag für die Suche zurückgibt.

mbp13.test.us   www.test.us DNS Standard query 0x1c5e  SSHFP www
www.test.us   mbp13.test.us DNS Standard query response 0x1c5e No such name

Vergleiche mit ssh www.test.us; was auch mit der Nachricht fehlschlägt

No matching host key fingerprint found in DNS.

Die Paketerfassung zeigt jedoch, dass DNS den Eintrag tatsächlich zurückgibt.

mbp13.test.us   www.test.us DNS Standard query 0x0ebd  SSHFP www.test.us
www.test.us   mbp13.test.us DNS Standard query response 0x0ebd  SSHFP SSHFP`

Erstens ist es ein wenig beunruhigend, dass die Fehlermeldung in beiden Fällen gleich ist. Ich kann einige Einträge hinzufügen, um Fall 1 zu beheben, in dem keine Einträge zurückgegeben werden, aber das große Problem ist Fall 2. DNS funktioniert und die SSHFP-Einträge werden an den ssh-Client zurückgegeben. Nach der Antwort auf die DNS-Abfrage werden keine Pakete gesendet, und der SSH-Client zeigt sofort die Nachricht "Kein passender Fingerabdruck" an. Dies bedeutet, dass entweder alle SSH-Clients, mit denen ich teste, defekt sind oder der in DNS gespeicherte Fingerabdruck falsch ist und nicht übereinstimmt. Ich bezweifle, dass es die Clients sind. Warum ist der Fingerabdruck in DNS falsch? Die Fingerabdrücke wurden mit den eingebauten ssh-Tools ssh-keygen generiert, wie am Anfang dieses Beitrags beschrieben. Das Problem wird auch nicht durch die Tatsache behoben, dass die Fingerabdrücke je nach Kontext in unterschiedlichen Formaten angezeigt werden.

DNS record format:      ad04dfaf343a93beeb939eed1612168f7eadbed7
ssh client mesg format: 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c

Hat jemand Vorschläge, warum die von ssh-keygen -r ausgegebenen Fingerabdrücke nicht mit den öffentlichen Schlüsseln übereinstimmen, die vom gleichen ssh-Server zurückgegeben werden?

Update3

Ich bin bei meiner letzten Option. Wenn mich nicht jemand vor dem Wochenende in die richtige Richtung weist, werde ich meinen Samstag damit verbringen, eine doppelte Umgebung mit VMs zu erstellen, die vollständig auf OpenBSD basieren. Da OpenBSD OpenSSH besitzt, müssten dies ideale Bedingungen sein, damit SSHFP über DNS funktioniert. Wenn ein OpenBSD OpenSSH-Server mit Bindung, der einen OpenBSD OpenSSH-Client bedient, nicht funktioniert, ist SSHFP wie implementiert fehlerhaft und ich werde die Dinge in die OpenBSD-Foren verschieben und möglicherweise einen Fehlerbericht einreichen. Ich hoffe immer noch, dass mir etwas Offensichtliches fehlt und dass eine hilfreiche Antwort mein Wochenende retten wird.

Anscheinend wurden meine Probleme durch zwei verschiedene Probleme verursacht.

Problem Nr. 1 SSHFP unterstützt die Verwendung von Suchpfaden nicht. Wenn Sie also "domain example.com" zu /etc/resolv.conf hinzufügen, erwarten Sie, dass ssh myhost mit SSHFP funktioniert, da reguläres ssh den Namen korrekt in myhost.example.com auflöst. Anscheinend sind sich die OpenBSD-Entwickler des Problems bewusst, da vor 2 Jahren ein Patch veröffentlicht wurde, der jedoch nie angewendet wurde. Stattdessen wurde ein ssh_config-Hack vorgeschlagen, aber das scheint auch nicht zu funktionieren. Die Lösung für das erste Problem besteht also darin, dass der vollqualifizierte Domänenname immer mit SSHFP verwendet werden muss.

Problem Nr. 2 Mit FQDNs zur Lösung des vorherigen Problems funktioniert alles, wenn ich die aktuelle Version des OpenSSH-Clients OpenSSH_6.1 verwende. Der OpenSSH_5.8p2-Client auf meinem FreeBSD-System kann die SSHFP-Einträge für einen neuen OpenSSH_6.1-Server finden, kann jedoch den vom DNS empfangenen Fingerabdruck nicht mit dem vom Server empfangenen abgleichen. Der OpenSSH_5.9p1-Client auf meinem OS X 10.8.2-Computer kann nicht einmal die SSHFP-Einträge für einen neuen OpenSSH_6.1-Server abrufen, obwohl er eine Never-Version des Clients als der FreeBSD-Computer ist. Offensichtlich ist es nicht möglich, die nicht vorhandenen SSHFP-Datensätze mit dem vom OpenSSH-Server zurückgegebenen Fingerabdruck abzugleichen. Schließlich erzeugt ssh-keygen auf der FreeBSD-Box schlechte SSHFP-Datensätze gemäß den OpenSSH_6.1-Clients, die sich über einen MITM-Angriff beschweren, da sie dies nicht tun. t entspricht dem vom Server zurückgegebenen Fingerabdruck. Die Lösung scheint zu sein, dass Sie die aktuelle Version von OpenSSH-Client und -Server ausführen müssen, damit SSHFP funktioniert. Die Verwendung einer älteren Version des Clients oder des Servers führt zu Problemen.

Abschließende Gedanken Die Verwendung von SSHFP mit DNS ist anscheinend zu modern, um in einer gemischten Betriebssystemumgebung verwendet zu werden, und alles funktioniert "nur", da die Nicht-OpenBSD-Betriebssysteme OpenSSH Portable portieren müssen, das zum Zeitpunkt der Portierung veraltet ist. Möglicherweise ist SSHFP in drei bis fünf Jahren so stabil, dass auch ältere Versionen, die auf andere Betriebssysteme portiert sind, stabil und mit der neuesten Version kompatibel sind.

Der Hostname des Servers, zu dem SSH eine Verbindung herstellt, muss genau mit dem Hostnamen im SSHFP-Datensatz übereinstimmen. Das heißt, es reicht nicht aus, nur die beiden Hostnamen in dieselbe IP-Adresse aufzulösen. Daher ssh wwwfunktioniert es nicht für SSHFPs, die für www.test.us. bestimmt sind, es sei denn, www befindet sich in Ihrer SSH-Konfiguration wie folgt:

Host www
    Hostname www.test.us

Versuchen Sie es ssh www.test.us.

Sie müssen den Dateinamen des öffentlichen Schlüssels des Dienstes angeben, für den Sie DNS-Einträge erstellen. Andernfalls werden Ihre persönlichen öffentlichen Schlüsseldateien aus .ssh / *. Pub als Standard-Fallback verwendet.

ssh-keygen -r vm1.test.us -f /etc/ssh/ssh_host_rsa_key.pub