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).