L’empreinte digitale de la clé de l’hôte lors de la connexion SSH diffère de celle lors de la génération de la clé
S'il vous plaît excuser la longue histoire, je ne suis pas sûr de sa pertinence.
Les ordinateurs "S" et "C" sont sur un réseau local. Ils ont des adresses ipv4 non routables sur le même segment et sont protégés du pare-feu de toute tentative de connexion entrante.
'S' obtient Ubuntu 16.04.x LTS Server installé, sans tête, et openssh-server, et une adresse IP statique. Tout le reste sur "S" a toujours les paramètres par défaut.
Sur 'C' avec le client OpenSSH:
$ ssh [email protected]
Et j'accepte la clé d'hôte proposée et tout fonctionne comme prévu. Sur le Shell à S, je lance apt-get update et ugprade.
Maintenant, je configure le client sur C avec des paramètres clairs, pour utiliser l'authentification par clé ou par mot de passe. Et je génère des clés sur C, ed25519 et RSA.
Puis reconnectez-vous à S, le message de bienvenue indique qu’il faut redémarrer. En remettant à plus tard, je déplace toutes les clés de serveur par défaut vers un répertoire de sauvegarde et en génère de nouvelles (pour contrôler les paramètres de keygen et s’assurer que seuls les paramètres forts sont présents). Cela fonctionne comme prévu et affiche un pictogramme ASCII pour chaque touche.
Maintenant, redémarrez S en supprimant la session de C. Ensuite, reconnectez-vous à S maintenant, bien sûr, les clés de son hôte sont modifiées et, grâce à ma configuration prudente, un message effrayant vous oblige à supprimer l'ancienne clé de l'hôte de ~/.ssh/connus_hôtes. Alors je fais ça et je recommence à me connecter.
L'art et l'empreinte ASCII sont différents, comme prévu. Cependant, ils ne sont pas d'accord avec ceux qui étaient affichés lorsque je générais les clés.
Je vais de l'avant et me connecte parce que je fais confiance à la situation (avec un pare-feu, etc.). Maintenant sur S, la sortie de
$ ssh-keygen -lv -f ssh_Host_ed25519_key.pub
est toujours le même que quand je générais les clés:
256 SHA256:<longStringTheFirstHere> root@S (ED25519)
+--[ED25519 256]--+
<ASCII art follows>
Cependant, en même temps, je peux me connecter à nouveau à partir d'un autre shell et la clé d'hôte présentée est la suivante:
256 SHA256:<longStringTheSecondHere> root@S (ED25519)
+--[ED25519 256]--+
<different ASCII art>
J'essaie donc de comprendre pourquoi il y a cette différence. Quelque chose a mal tourné? Y a-t-il un problème de sécurité? Plus probablement quelque chose me manque mais j'aimerais savoir ce que c'est.
J'ai trouvé de nombreuses pages sur des sujets connexes, mais pas tout à fait à ce sujet.
Résolu ma propre question. L’indice se trouvait au bas de l’art ASCII. Sur le résultat de cette commande:
$ ssh-keygen -lv -f ssh_Host_ed25519_key.pub
en bas se trouve:
+----[SHA256]-----+
Tandis que vous êtes au bas de l’art ASCII lorsque le serveur présente sa clé lors de la connexion:
+-----------------+
man ssh-keygen révèle le paramètre -E qui vous permet de spécifier un algorithme de hachage. Avec SHA256, le résultat est identique à celui obtenu sans, mais avec md5, le résultat obtenu lors de la connexion est le suivant:
$ ssh-keygen -lv -E md5 -f ssh_Host_ed25519_key.pub
Alors maintenant, je suis convaincu que rien n’est faux, les empreintes digitales ne différaient que par algo et c’était la même clé après tout.