http://fanf.livejournal.com/130577.html

J'avais déjà testé les enregistrements SSHFP afin de valider, via le DNS, les clés publiques de mes serveurs persos. Maintenant que mes desktops sont sous Jessie, dans laquelle la version packagée d'openssh-client supporte les condensats sha256 dans le RDATA des enregistrements SSHFP ainsi que le type ecdsa, entre autres choses, c'est l'occasion de déployer pour de vrai.

Il vous faut :
   * Des zones DNS signées avec DNSSEC sinon l'intérêt de SSHFP est nul.
      Si vos zones ne sont pas signées (cas d'un hébergeur, comme OVH pour les zones comme kimsufi.com, par exemple), laissez tomber. Utiliser une zone signée + CNAME ne fonctionnera pas : CNAME ne peut pas se cumuler avec un autre type d'enregistrement. La seule piste envisageable, c'est de dupliquer, dans ma zone signée les enregistrements de type A et AAAA et d'y ajouter les enregistrements SSHFP mais c'est vraiment crade : vous dupliquez dans une zone des informations d'une autre zone d'où un coût en maintenance supérieur et un risque d'erreur accru. ;


   * Si vous utilisez ssh-keygen pour générer les enregistrements SSHFP, il vous faut la partie publique des clés de votre serveur au format openssh. Si vous avez du dropbear (exemple : OpenWRT), il faudra d'abord la convertir.
       * sudo apt-get install dropbear
       * /usr/lib/dropbear/dropbearconvert dropbear openssh <cle_dropbear> <cle_dropbear>.ssh
       * La partie publique n'est pas stockée sur mon périphérique OpenWRT... générons-la à partir de la partie privée que nous venons de convertir (https://askubuntu.com/questions/53553/h … rivate-key) : ssh-keygen -y -f <cle_dropbear>.ssh > <cle_dropbear>.ssh.pub

       * ssh-keygen -r <hostname> -f <cle_dropbear>.ssh.pub . Deux enregistrements sont produits. Le plus court utilise sha1 pour produire le condensat, le plus long utilise sha256. De nos jours, avec sha1 qui commence à montrer des signes de faiblesse, il faut utilise sha256.


   * Publier les enregistrements SSHFP.


   * Un openssh-client compilé avec la lib ldns lui permet de faire les vérifications DNSSEC et donc de s'assurer que l'information n'a pas été altérée. Ce n'est pas le cas avec Debian : openssh-client n'est pas compilé avec libldns (ldd $(whereis -b ssh) pour vérifier). Donc, il faut impérativement un récursif-cache validant sur votre machine (voir dnssec-trigger, http://shaarli.guiguishow.info/?uEnUXw) ou, à défaut sur le réseau local qui doit alors être de confiance (VPN, réseau domestique...) et pas de WiFi (oui, même WPA1|2 car la clé est partagée entre les utilisateurs du réseau. Et même avec ça, il reste le problème des switchs réseaux mais comme d'hab, ça dépend de qui vous voulez vous protéger).
       Il faut bien comprendre que, sans la lib ldns, la validation des enregistrements DNSSEC est effectué par le récursif-cache validant que vous utilisez. Celui-ci signale qu'il a réalisé le travail de vérification en plaçant le flag "AD" (Authenticated Data) dans le header du message DNS... qui n'est pas signé : un MITM (ou un mensonge du récursif-cache utilisé) reste donc possible.

   * Activer la vérification des SSHFP en ajoutant ceci à votre .ssh/config :
       « Host *
             VerifyHostKeyDNS=yes »

     Vous pouvez aussi restreindre seulement aux machines dont vous savez que le déploiement est effectif. Ça ne change rien pour les machines qui n'ont pas de SSHFP associé à leur clé publique, known_hosts sera alors utilisé mais vous ne ferez pas de requêtes DNS inutiles pour ces machines-là.

     À partir de ce moment-là, SSH n'utilise plus .ssh/known_hosts mais uniquement le DNS. À la mise en service d'une nouvelle machine (virtuelle ou non), il faudra publier son SSHFP avant de faire un SSH sinon l'absence de réponse sera mise en cache et une validation manuelle sera nécessaire (comme sans VerifyHostKeyDNS quoi). Même chose lors d'un changement de la clé du serveur : il faudra pré-publier et attendre l'expiration du TTL du vieil enregistrement SSHFP avant d'être sûr que le nouveau arrive dans le cache... Les clients n'ont plus besoin de mettre à jour leur known_hosts.


   * Vérifier : ssh -vvv serveur :
       * Si vous utilisez un récursif-cache qui ne valide pas :
         « debug3: verify_host_key_dns   
           debug1: found 1 insecure fingerprints in DNS
           debug1: matching host key fingerprint found in DNS »
         Et SSH vous demandera une confirmation manuelle de la clé du serveur.

       * Avec un récursif-cache validant :
         « debug3: verify_host_key_dns
           debug1: found 1 secure fingerprints in DNS
           debug1: matching host key fingerprint found in DNS »
         Et vous êtes connectés automagiquement à votre serveur.