SSHFP, faciliter l'authentification d'un serveur SSH à partir d'un client
Le protocole SSH est fortement utilisé dans les domaines des réseaux et de l'administration système pour notamment prendre le contrôle de machines à distance. Il fait parti, au même titre que TLS, des protocoles les plus utilisés. Hors, concernant l'authentification, SSH et TLS ne fonctionne pas du tout de la même manière.
I. Introduction
En effet, pour prouver l'identité des serveurs, SSL/TLS se base sur des tiers de confiance, appelés Autorités de certification, qui sont en charge de générer et signer les certificats utilisés.
Concernant le protocole SSH, le tiers de confiance n'existe pas. Ainsi lors d'une première connexion, le client reçoit un message d'avertissement dans lequel l'empreinte de la clef publique du serveur lui est présentée. Le client peut alors faire le choix d'accepter cette empreinte ou de la refuser (la connexion se coupe dans ce cas de figure).
Lorsque je me connecte sur une machine disposant d'un service SSH, le seul moyen de m'assurer de son identité est de connaître son empreinte de clef au préalable afin de pouvoir la comparer avec celle qui m'est donnée lors de l'établissement de la connexion. Sans cela, je peux facilement être vulnérable à une attaque Man-in-the-Middle et ainsi envoyer mon mot de passe à un attaquant en croyant me connecter au serveur légitime.
Si je dois me servir du protocole SSH sur une poignée de machines, la récupération de l'empreinte de la clef publique en amont pour chaque équipement reste envisageable. Mais comment-faire avec une cinquantaine ou une centaine d'hôtes disposant d'un daemon SSH ? C'est là qu'intervient SSHFP.
II. Le protocole SSHFP
Le protocole SSHFP (rfc 4255) permet de publier les empreintes de clefs publiques des hôtes disposant d'un service SSH dans votre zone DNS. Ainsi, lorsque le client établira une nouvelle connexion auprès d'un serveur SSH, il comparera l'empreinte de la clef publique proposée par le serveur avec celles enregistrées dans la zone DNS. Si elles sont identiques, alors l'identité du serveur est prouvée.
Attention ! Ce mécanisme est fiable dans le cas où la zone DNS a été signée à l'aide de DNSSEC. Dans le cas contraire, divers attaques peuvent mettre à mal la réponse fournie par le serveur DNS.
III. Et techniquement ?
Pour ma part, je ne me sers exclusivement que d'OpenSSH, le logiciel fourni par les developpeurs du système Unix OpenBSD. Dans un premier temps, je vais devoir récupérer l'empreinte des clefs publiques du serveur anakin.tatooine.org afin de les enregistrer dans ma zone DNS :
anakin.tatooine.org. IN SSHFP 1 2 3ea300d6fce6dcf3dc04ef559891cceb8c7ec63b1577fdd0dddd9f81f4f8cee1
anakin.tatooine.org. IN SSHFP 2 1 d231c3aca8f3c4f4eee8725746091238a45d942d
anakin.tatooine.org. IN SSHFP 2 2 4d33c5c42c3da32df81c46d4c52faf9bafb9ee29f3a3abee943f4f805de9707a
anakin.tatooine.org. IN SSHFP 3 1 0c7dd8a28716d602f578425d7a629e88d5e80ce2
anakin.tatooine.org. IN SSHFP 3 2 2ebc65713a7634ca6a2807524aecd3331be1c2229d63f3b9a7c2f5882618ab98
anakin.tatooine.org. IN SSHFP 4 1 d1848eda9d6ef234d4eb67d7b7d1a5a43655e1b4
anakin.tatooine.org. IN SSHFP 4 2 5a0036199206705246c502fcfb72e8d05222161258aafeb3f2499d5fabb2d695
Sur une Debian Jessie, nous récupérons les entrées présentées ci-dessus. Il y en a 4, car votre service SSH a généré par défaut 4 paires de clefs avec des algorithmes de chiffrement différents (RSA, DSA, ECDSA, ed25519). En fonction du client et de ses préférences (où ce qu'il peut supporter), l'un de ces algorithmes sera privilégié. Nous pouvons également remarquer que deux empreintes nous sont proposées l'une basée sur SHA-1, l'autre sur SHA-256.
Il nous suffit maintenant de publier ces éléments dans la zone DNS concernée :
Enfin, imaginons que Bob souhaite se connecter en SSH sur le serveur anakin.tatooine.org et qu'il ne connaisse pas en amont les empreintes de clefs publiques de cet équipement. Aucun souci, SSHFP va lui permettre de résoudre ce problème et lui donner une réponse quant à l'identité de la machine sur laquelle il essaye de se connecter :
En fonction de la présence de l'empreinte dans la zone DNS ou non, voici les messages que vous serez susceptible de rencontrer pendant votre connexion :
Si l'on souhaite se dispenser de taper l'option VerifyHostKeys à chaque fois, on peut bien entendu utiliser un alias ou rentrer ce paramètre dans le fichier de configuration du client SSH /etc/ssh/ssh_config :
VerifyHostKeyDNS yes
Ce protocole rappelle bien entendu l'utilisation de DANE/TLSA dans le cadre du protocole TLS. Il est cependant relativement important et intéressant car il permet d'identifier de manière relativement fiable le serveur sur lequel on établie une connexion. Contrairement à TLS, SSH ne repose pas sur la notion de tiers de confiance pour garantir l'identité des machines sur lesquelles on se connecte. La contrainte (et non des moindres) est d'avoir implémenté DNSSEC sur son ou ses serveurs DNS faisant autorité au préalable.
IV. Références
https://tools.ietf.org/html/rfc4255
http://jpmens.net/2012/02/01/on-collecting-ssh-host-keys-for-sshfp-dns-records/
http://www.bortzmeyer.org/4255.html
https://www.octopuce.fr/declaration-automatique-des-cles-ssh-dans-le-dns-via-sshfp/