Vérifier une clé SSH
Publié : sam. 25 juin 2016, 18:43
SSH permet de se connecter à distance sur un serveur ou le démon sshd est lancé. Il y a assez de tutoriels sur la toile pour la mise en place - ce n'est donc pas l'objet de ce post.
Ce qui nous intéresse ici, c'est que lors de la connexion, on voit apparaître des lignes comme suit
Pour savoir si l'empreinte de notre serveur est la bonne, on aura préalablement noté, après l'installation du paquet openssh-server, l'empreinte ECDA comme suit :
Si les deux clés correspondent, tout va bien. Si vos clés, diffèrent, il y a de "grandes oreilles" sur la ligne qui font rien qu'à vous espionner ! (attaque de type "homme du milieu" - ou man in the middle).
Nous touchons là un problème de base de SSH : si vous gérez vos propres serveurs, vous êtes le maître des clés, et vous trouverez sûrement rapidement la cause du problème.
Mais si vous envoyez vos fichiers via SFTP sur un hébergement mutualisé, et que la clé SSH change soudainement, vous n'avez aucun moyen de savoir si c'est normal (par exemple un hébergeur qui aurait migré le dit serveur) ou pas... Les hébergeurs sont trop stupides pour envoyer la nouvelle empreinte à leurs clients, et l'on se retrouve dans une situation ou, une fois encore, la confiance est censée prendre le dessus sur la raison...
A noter que le "UserKnownHostsFile=/dev/null" est là pour forcer la revérification obligatoire de l'hôte, qui a lieu à la première connexion, mais est ensuite enregistré dans le fichier known_hosts. L'option FingerprintHash permet de forcer l'affichage, ici au format MD5. Là encore, suivant votre système, certaines distributions récentes utilisent désormais le SHA256 (FingerprintHash=sha256).
Ce qui nous intéresse ici, c'est que lors de la connexion, on voit apparaître des lignes comme suit
Code : Tout sélectionner
$ ssh -XY -o FingerprintHash=md5 -o "UserKnownHostsFile=/dev/null" root@192.168.1.10
The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ECDSA key fingerprint is 1d:ab:a3:71:45:6c:a5:11:da:bc:cb:d5:2f:e0:66:fa.
Are you sure you want to continue connecting (yes/no)?
Code : Tout sélectionner
# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 1d:ab:a3:71:45:6c:a5:11:da:bc:cb:d5:2f:e0:66:fa root@ma_machine (ECDSA)
Nous touchons là un problème de base de SSH : si vous gérez vos propres serveurs, vous êtes le maître des clés, et vous trouverez sûrement rapidement la cause du problème.
Mais si vous envoyez vos fichiers via SFTP sur un hébergement mutualisé, et que la clé SSH change soudainement, vous n'avez aucun moyen de savoir si c'est normal (par exemple un hébergeur qui aurait migré le dit serveur) ou pas... Les hébergeurs sont trop stupides pour envoyer la nouvelle empreinte à leurs clients, et l'on se retrouve dans une situation ou, une fois encore, la confiance est censée prendre le dessus sur la raison...
A noter que le "UserKnownHostsFile=/dev/null" est là pour forcer la revérification obligatoire de l'hôte, qui a lieu à la première connexion, mais est ensuite enregistré dans le fichier known_hosts. L'option FingerprintHash permet de forcer l'affichage, ici au format MD5. Là encore, suivant votre système, certaines distributions récentes utilisent désormais le SHA256 (FingerprintHash=sha256).