Échec de la configuration des empreintes digitales ssh sur le DNS pour remplacer les hôtes connus

Les enregistrements SSHFP ont été générés sur le serveur ssh comme suit, puis ajoutés à la zone dans bind:

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

Les enregistrements requis peuvent être récupérés à partir du client ssh via DNS comme indiqué:

$ 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

Cependant ssh sur le client ne parvient pas à les trouver lors de la connexion:

$ 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)?

Des idées pour expliquer pourquoi cela échoue? Je sais que DNSSEC est requis pour le sécuriser et que je devrais recevoir un avertissement car DNSSEC n'est pas actuellement activé. J'espère que cela fonctionnera sans DNSSEC avant de commencer à aborder cela comme un problème supplémentaire.

Le serveur ssh est FreeBSD 9.1 avec OpenSSH_5.8p2_hpn13v11 et héberge également DNS à l'aide de BIND 9.8.3-P4. J'ai essayé de me connecter depuis OS X 10.8.2 avec OpenSSH_5.9p1 ainsi qu'avec Arch Linux 3.6.10-1-ARCH avec OpenSSH_6.1p1.

Mise à jour

Dans une autre tentative pour résoudre ce problème, j'ai monté une nouvelle machine virtuelle OpenBSD 5.2 qui a OpenSSH_6.1 intégré en tant que serveur ssh. Puisque toutes les autres implémentations du serveur OpenSSH ne sont que des ports de celui d'OpenBSD, cela devrait sûrement fonctionner. Sur le serveur, je génère les enregistrements SSHFP:

# 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

Je les ajoute au serveur de liaison FreeBSD et je recharge le nom. Ensuite, testez pour voir si je peux accéder aux enregistrements:

$ 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

Les enregistrements sont clairement servis via DNS, donc j'essaie d'utiliser ssh:

$ 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)?

À ce stade, je pense qu'il est sûr d'éliminer les clients et les serveurs ssh comme point de défaillance. Au lieu de cela, je vais me concentrer sur le serveur DNS. Sauf si quelqu'un a une suggestion de l'endroit où chercher, je suppose que je suis coincé avec la capture de paquets et la fouille à travers eux pour trouver des indices.

Update2

D'accord, voici les résultats de mes captures de paquets. ssh www; échoue avec la norme

No matching host key fingerprint found in DNS.

et la capture de paquets montre que DNS ne parvient pas à renvoyer un enregistrement pour la recherche.

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

Comparez avec ssh www.test.us; qui échoue également avec le message

No matching host key fingerprint found in DNS.

cependant, la capture de paquets montre que DNS renvoie réellement l'enregistrement.

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`

Tout d'abord, il est un peu déconcertant que le message d'erreur soit le même pour les deux cas. Je peux ajouter quelques enregistrements pour corriger le cas 1 où aucun enregistrement n'est retourné, mais le gros problème est le cas 2. DNS fonctionne et les enregistrements SSHFP sont retournés au client ssh. Aucun paquet n'est envoyé après la réponse à la requête DNS et le client ssh affiche immédiatement le message d'empreinte digitale sans correspondance. Cela signifie que tous les clients ssh avec lesquels je teste sont cassés ou que l'empreinte digitale stockée dans DNS est incorrecte et ne correspond pas. Je doute que ce soit les clients, alors pourquoi l'empreinte digitale du DNS est-elle incorrecte? Les empreintes digitales ont été générées à partir des outils ssh intégrés ssh-keygen comme décrit au tout début de cet article. De plus, le problème n'est pas résolu par le fait que les empreintes digitales sont affichées dans différents formats en fonction du contexte.

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

Quelqu'un at-il des suggestions quant à la raison pour laquelle les empreintes digitales produites par ssh-keygen -r ne correspondent pas aux clés publiques renvoyées par le même serveur ssh?

Update3

J'en suis à ma dernière option. À moins que quelqu'un ne me pointe dans la bonne direction avant le week-end, je passerai mon samedi à créer un environnement en double à l'aide de machines virtuelles entièrement basées sur OpenBSD. Étant donné qu'OpenBSD possède OpenSSH, cela devrait être des conditions idéales pour que SSHFP sur DNS fonctionne. Si un serveur OpenBSD OpenSSH avec liaison servant un client OpenBSD OpenSSH ne fonctionne pas, alors SSHFP est cassé tel qu'implémenté et je déplacerai les choses sur les forums OpenBSD et éventuellement déposerai un rapport de bogue. J'espère toujours qu'il me manque quelque chose d'évident et qu'une réponse utile sauvera mon week-end.

ssh dns bind

— Michael Yasumoto
source

Avez-vous essayé de vous connecter pour vous connecter explicitement à www.test.us?

— Ulrich Dangel

Oui. Désolé, j'aurais dû mentionner que j'ai essayé toutes les variantes: ssh www; ssh www.test.us; ssh www.test.us .; Tous aboutissent à la même réponse.

— Michael Yasumoto

Il peut être intéressant de voir dans Wireshark / tcpdump ce qui est interrogé depuis le serveur DNS et quelle réponse est envoyée. Connaître les requêtes et les réponses exactes devrait aider à trouver le problème.

— Gert van den Berg

Gert, j'ai répondu dans une mise à jour ci-dessus parce que je ne pouvais pas insérer la réponse dans cette zone de commentaire.

— Michael Yasumoto

Essayez de vous connecter directement par adresse IP - pour moi, il semble que sshles enregistrements DNS ne correspondent pas au nom d'hôte que vous essayez d'atteindre.

— peterph

Apparemment, mes problèmes étaient dus à deux problèmes différents.

Problème # 1 SSHFP ne prend pas en charge l'utilisation des chemins de recherche. Donc, si vous ajoutez "domain example.com" à /etc/resolv.conf, vous vous attendez à ce que ssh myhost fonctionne avec SSHFP car ssh normal résoudra correctement le nom en myhost.example.com. Apparemment, les développeurs d'OpenBSD sont conscients du problème depuis qu'un correctif a été publié il y a 2 ans mais qu'il n'a jamais été appliqué. Au lieu de cela, un hack ssh_config a été suggéré mais cela ne semble pas fonctionner non plus. La solution au premier problème est donc que le nom de domaine complet doit toujours être utilisé avec SSHFP.

Numéro 2 En utilisant des noms de domaine complets pour résoudre le problème précédent, tout fonctionne si j'utilise la version actuelle du client OpenSSH qui est OpenSSH_6.1. Le client OpenSSH_5.8p2 sur mon système FreeBSD est capable de trouver les enregistrements SSHFP pour un nouveau serveur OpenSSH_6.1, mais il ne peut pas faire correspondre l'empreinte digitale qu'il reçoit du DNS avec celle qu'il reçoit du serveur. Le client OpenSSH_5.9p1 sur ma machine OS X 10.8.2 n'est même pas en mesure de récupérer les enregistrements SSHFP pour un nouveau serveur OpenSSH_6.1 bien qu'il ne soit jamais une version du client que la machine FreeBSD. Il est évidemment impossible de faire correspondre les enregistrements SSHFP inexistants avec l'empreinte digitale renvoyée par le serveur OpenSSH. Enfin, ssh-keygen sur la boîte FreeBSD produit de mauvais enregistrements SSHFP selon les clients OpenSSH_6.1 qui se plaignent d'une attaque MITM depuis qu'ils ne t correspondre à l'empreinte digitale renvoyée par le serveur. La solution semble être que vous devez exécuter la version actuelle du client et du serveur OpenSSH pour que SSHFP fonctionne. L'utilisation d'une ancienne version du client ou du serveur pose problème.

Réflexions finales L' utilisation de SSHFP avec DNS est apparemment trop avant-gardiste pour être utilisée dans un environnement de système d'exploitation mixte et tout fonctionne "simplement", car les systèmes d'exploitation non OpenBSD doivent porter OpenSSH portable qui est obsolète au moment où il est porté. Peut-être que dans 3 à 5 ans, SSHFP sera suffisamment stable pour que même les anciennes versions qui sont portées sur d'autres systèmes d'exploitation soient également stables et compatibles avec la dernière version.

— Michael Yasumoto
source

Malgré le fait que OS X (10.9) inclut désormais une version 6.X d'OpenSSH, SSHFP ne fonctionne toujours pas en raison d'une implémentation OS X cassée, comme signalé par GitHub. Le remplacement par un autre client OpenSSH tel que celui de MacPorts est actuellement la seule solution.

— Michael Yasumoto

Le nom d'hôte du serveur auquel SSH se connecte doit correspondre exactement au nom d'hôte dans l'enregistrement SSHFP. Autrement dit, il ne suffit pas que les deux noms d'hôtes se résolvent à la même adresse IP. Ainsi, ssh wwwne fonctionnera pas pour les SSHFP qui sont pour www.test.us., sauf si www est dans votre configuration SSH comme ceci:

Host www
    Hostname www.test.us

Essayez ssh www.test.us.

— htoip
source

Désolé, mais il semble que vous n'ayez pas lu mon article complet ci-dessus. J'ai testé en utilisant des noms de domaine pleinement qualifiés (FQDN) et ce n'était pas le problème.

— Michael Yasumoto

Vous devez fournir le nom de fichier de la clé publique du service pour lequel vous créez des enregistrements DNS. Sinon, il utilisera vos fichiers de clés publiques personnels à partir de .ssh / *. Pub comme solution de repli par défaut.

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

— un loup
source