Utiliser le DNS pour vérifier la clé publique de ses serveurs SSH, ça fait longtemps que je connais mais que je n'ai pas déployé. Et pour cause : sans DNSSEC, ce n'est pas une superbe avancée. Mais maintenant que ça m'est revenu à l'esprit et que mes zones DNS sont signées, j'ai voulu retenter.
Pour générer les enregistrements DNS de type SSHFP, on peut utiliser « ssh-keygen -r » mais je lui préfère cette méthode manuelle :
https://confluence.clazzes.org/display/KH/SSHFP+records%3A+DNS+providing+public+ssh+host+keys car elle permet, entre autres, de générer toutes les empreintes correspondantes à chacune des clés du serveur, quel que soit son algo (rsa,dsa,ecdsa), en un seul coup.
Regardons le rdata d'un enregistrement de type SSHFP pour notre culture : « x y condensat ». x = type de clé (1 = RSA, 2 = DSA, 3 = ECDSA). y = fonction de hachage utilisée pour générer le condensat (1 = SHA1 ; 2 = SHA256). Cf :
http://tools.ietf.org/html/rfc4255 et
http://tools.ietf.org/html/rfc6594
Publier les enregistrements générés plus haut dans votre zone, forcer un resign de votre zone, vérifier que le RRset SSHFP est publié (dig +dnssec SSHFP machine.example.com), tester avec un ssh -o VerifyHostKeyDNS=yes -v <serveur> et ... ça ne fonctionne pas :
debug1: Server host key: ECDSA [fingerprint blabla]
debug1: found 1 secure fingerprints in DNS
Error calculating host key fingerprint.
Par défaut, le serveur envoie sa clé ecdsa. Le RFC 6594, publié mi 2012, ajoute le support des clés ecdsa (et de l'algo de hachage SHA256 pour le rdata) au rtype SSHFP. OpenSSH supporte cela depuis sa version 6.1 (
http://www.openssh.com/txt/release-6.1 - « Add support for RFC6594 SSHFP DNS records for ECDSA key types. bz#1978 ») ... mais dans Debian Stable, nous avons uniquement la version 6.0 ... Ce qui explique cette erreur ainsi que l'erreur « export_dns_rr: unsupported algorithm » quand on tente un ssh-keygen -r sur la clé ecdsa.
Avec la version 6.6 présente dans les backports (apt-get install -t wheezy-backports openssh-client), tout fonctionne comme attendu :
debug1: Server host key: ECDSA [fingerprint blabla]
debug1: found 1 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_ecdsa_verify: signature correct
On peut donc ajouter ceci à notre ssh_config :
Host *
VerifyHostKeyDNS=yes
Évidemment, si vous n'avez pas un récursif-cache validant sur votre machine ou sur votre réseau local de confiance, vous subissez le problème du dernier kilomètre (DNSSEC toussa) et cette publication de RR de type SSHFP ne vous avance pas vraiment niveau sécurité.
Pour ceux qui ne veulent pas utiliser les backports (je vous comprends) ni attendre la prochaine Debian Stable ni changer de système (Debian > *, je vous comprends), il existe la directive de config' « HostKeyAlgorithms » que l'on peut préciser dans le ssh_config. Par défaut, elle vaut (cf le man) :
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,
ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
ssh-ed25519,ssh-rsa,ssh-dss
On voit bien qu'ecdsa passe avant tout. On peut la forcer à une valeur sans ecdsa :
« Host *
HostKeyAlgorithms=ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
VerifyHostKeyDNS=yes »
Personnellement, je ne le ferai pas. J'ai encore confiance en les dev' d'OpenSSH et en les mainteneurs Debian. Si ecdsa passe en priorité, je laisse et j'attends le support des SSHFP ecdsa+sha256 (même si ecdsa n'est pas mieux que rsa/dsa mais juste moins gourmand à sécurité équivalente et que, du coup, l'impact en sécurité de forcer rsa doit être négligeable).
