Résumé : ssh -o VerifyHostKeyDNS=yes

Vous avez tous déjà touché à un ssh. Rappelez-vous votre première connexion :

$ ssh 127.0.0.1

The authenticity of host ‘127.0.0.1 (127.0.0.1)’ can’t be established.

RSA key fingerprint is d9:16:53:ef:84:cf:1a:ce:42:03:55:09:86:5c:0e:50.

Are you sure you want to continue connecting (yes/no)?

Mais qu’est-ce que c’est que ce bin’s ? Bon aujourd’hui vous êtes grands, vous le savez, il s’agit de vérifier que la machine à laquelle on parle est bien celle à laquelle on voulait parler. Pour faire cette vérification, il faut aller demander à une personne de confiance qui administre ou qui s’est déjà connectée à la machine, si l’empreinte que vous avez sous les yeux est la bonne.

En pratique personne ne le fait ! Si vous l’avez toujours fait, soit vous ne vous êtes jamais connecté avec ssh, soit vous êtes Rain-Man. Sinon vous êtes à peu près normal.

Par conséquent vous faites confiance aux pirates de tout poil pour ne pas avoir attaqué votre serveur au moment de votre première session. Question qui ne se pose plus par la suite où vous faites implicitement confiance à vos connexions précédentes.

Confiance relative

Que faire pour éviter le désagrément de cette première connexion ? Tout dépend de votre confiance. Vous pouvez avoir une confiance absolue en votre réseau de machines :

$ ssh -o StrictHostKeyChecking=no mamachine.toto.net

Ou alors vous pouvez avoir une confiance nulle et considérer toute connexion dont la clé n’a pas été ajoutée à la main comme une première connexion :

$ ssh -o StrictHostKeyChecking=yes mamachine.toto.net

La valeur par défaut est ask et est écrite dans /ect/ssh/ssh_config (ou ~/.ssh/config si vous en avez un).

Confiance toute aussi relative

Mais vous vous dites, pourquoi cette information n’est elle pas centralisée, il suffirait ainsi de faire confiance à une unique entité pour que toutes les connexions ssh soient « de confiance ».

Hé bien cette chose existe … presque. Vous pouvez mettre cette information dans votre serveur DNS sous la forme d’un champ SSHFP.

mamachine IN SSHFP 1 1 1d7b808b64aa57c2451d3635dc4dbb6931c8c715

1 et 1 indiquent les type de clé et sont suivis par la clé elle-même.

Ensuite vous vous connectez à votre machine pour la première fois

$ ssh -o VerifyHostKeyDNS=yes mamachine.toto.net

The authenticity of host ‘toto.localhost (127.0.0.2)’ can’t be established.

RSA key fingerprint is d9:16:53:ef:84:cf:1a:ce:42:03:55:09:86:5c:0e:50.

Matching host key fingerprint found in DNS.

Are you sure you want to continue connecting (yes/no)?

Presque, mais ssh ne fait pas confiance à votre serveur DNS et il vous pose donc quand même la question.

Confiance un peu plus relative

Pour que ssh fasse confiance à votre serveur DNS, il faut que ce soit un resolver DNSSEC. C’est à dire dns sécurisé. Donc à toute allure vous installez un resolver sécurisé, une zone DNSSEC, et tadaaam :

$ ssh -o VerifyHostKeyDNS=yes mamachine.toto.net

$ hosname

> mamachine.toto.net

Bravo ! vous pouvez maintenant gérer vos machines en toute quiétude. Sans vous préoccuper du fait que vous êtes en train de faire confiance à un resolver DNSSEC. Or pour ceux qui connaissent un peu, dnssec permet de faire confiance aux sources de données (le serveur qui sert la zone), mais n’impose rien dans le protocole entre le client et le resolver dns (seul un bit ad est présent et indique que le résolver a utilisé une procédure sécurisée). Ce qui veut dire que la la partie communication locale avec le dns n’est pas vraiment sécurisée …

Un peu plus loin

Vous pouvez quand même mettre en place vos entrées SSHFP, ca sera toujours mieux que rien, vous aurez une vérification disponible. Pour ne pas devoir récupérer à la main vos entrées SSHFP, vous pouvez utiliser ssh-keygen :

$ ssh-keygen -r localhost

127.0.0.1 IN SSHFP 1 1 1d7b808b64aa57c2451d3635dc4dbb6931c8c715

127.0.0.1 IN SSHFP 2 1 ba276a0efde89b9f041b4e42780ee317a48403b9

# prêt à être inséré dans la zone DNS

D’autre part si vous faites une zone signée dnssec (pour ne plus avoir de confirmation du tout) il faudra que vous ayez un resolver dns séparé de votre serveur de zone (lequel ne mettra pas le bit ad de lui-même). Sinon ssh ignorerait le fait que votre zone est sécurisée. Ceci implique donc une architecture suffisamment grande pour séparer les 2 ou le fait que vous ne travaillez que sur des serveur distants (dnsment parlant).

viaVérification automatique des fingerprint ssh – Linux Attitude.