Page 1 sur 1

Vérifier une clé SSH

Publié : sam. 25 juin 2016, 18:43
par le Manchot Masqué
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

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)?
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 :

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

Re: Vérifier une clé SSH

Publié : mar. 26 déc. 2017, 18:43
par juice
Très intéressant. J’ai pu tester un peu avec l’installation d’une archlinux.

Le format du fingerprint est le côté casse pied. Pas trouvé comment côté serveur lui afficher l’empreinte de la clé au format sha256…

Re: Vérifier une clé SSH

Publié : mer. 27 déc. 2017, 15:02
par samuel.degoul
L'option -E de ssh-keygen permet de spécifier l'algorithme de hachage.

J'ai déjà rencontré le problème : une debian stable sur le serveur avec une version relativement ancienne de SSH (et ssh-keygen) affichait l'empreinte en md5 alors que la commande ssh sur mon poste client l'affichait en sha256 ; dans ce cas, c'est la version la plus récente qui doit s'adapter, dans mon cas l'option FingerprintHash de la commande ssh côté client.

Re: Vérifier une clé SSH

Publié : dim. 31 déc. 2017, 16:31
par juice
En effet :

Côté serveur : ssh -V donne :
OpenSSH_5.8p1-hpn13v11, OpenSSL 1.0.1m-fips 19 Mar 2015

Pas d’option -E pour spécifier l'algorithme de hachage avec ssh-keygen.

Côté client :
OpenSSH_7.6p1, OpenSSL 1.1.0g 2 Nov 2017

Par contre il serait bon que je fasse une mise à jour ssh sur le serveur, qui a 8 ans. La version de paquet de mon Synology date un peu et je n’ai pas eu de mise à jour récemment. J’ai bien une version openssh - 5.9p1-1 avec ipkg mais je vais devoir bidouiller un peu la config…