Le message
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:1
Host key for server has changed and you have requested strict checking.
Host key verification failed.Un serveur prouve son identité avec sa clé d'hôte. Votre ordinateur a enregistré cette clé lors de votre première connexion. Il en a maintenant reçu une autre, et ssh s'est arrêté avant d'envoyer quoi que ce soit. Les deux informations dont vous avez besoin sont la nouvelle empreinte (la ligne SHA256:) et l'emplacement de l'ancienne entrée (known_hosts:1 est la ligne 1). Sur Debian et Ubuntu, le message propose aussi une commande ssh-keygen -R : lancez-la seulement après la vérification ci-dessous.
Cause légitime ou attaque ?
Causes courantes et sans danger :
- Le serveur a été reconstruit, réinstallé ou restauré, ce qui crée souvent de nouvelles clés d'hôte.
- L'adresse appartient maintenant à une autre machine : une nouvelle VM sur une IP cloud réutilisée, ou une Elastic IP déplacée.
- Un répartiteur de charge ou une paire de basculement vous envoie vers une machine aux clés différentes.
- Un port redirigé comme
localhost:2222mène maintenant ailleurs. - Un administrateur ou un service a changé les clés, comme GitHub avec sa clé d'hôte RSA en mars 2023.
- Le serveur ne propose plus le type de clé que vous aviez enregistré. Dans notre test, un serveur limité à RSA a déclenché cet avertissement pour un client qui avait enregistré sa clé ED25519.
Soyez méfiant quand personne ne peut expliquer le changement, quand il n'apparaît que sur un seul réseau comme un Wi-Fi public, ou quand il s'agit d'un serveur que personne n'a touché. Tant que vous ne savez pas, ne saisissez pas de mot de passe et n'exécutez rien dessus. Essayer depuis un autre réseau aide : si les empreintes diffèrent d'un réseau à l'autre, quelque chose interfère sur l'un d'eux.
Vérifier la nouvelle empreinte par un autre canal
Par un autre canal, c'est-à-dire par un chemin qu'un attaquant placé sur cette connexion ne contrôle pas : la console web de l'hébergeur, une console série, l'accès physique ou un collègue disposant d'un accès vérifié. Sur le serveur, exécutez :
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub256 SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU root@server (ED25519)Utilisez le fichier correspondant au type de clé nommé dans l'avertissement : ssh_host_rsa_key.pub ou ssh_host_ecdsa_key.pub pour les autres. La valeur doit correspondre exactement à l'avertissement. Certaines images cloud affichent aussi les empreintes dans le journal de la console au premier démarrage.
La commande ci-dessous montre seulement ce qu'envoie le serveur sur le chemin réseau actuel. Elle est pratique pour lire une valeur, mais elle ne prouve rien à elle seule, puisqu'un attaquant lui enverrait la même fausse clé :
ssh-keyscan -t ed25519 server | ssh-keygen -lf -Supprimer l'ancienne clé
ssh-keygen -R server# Host server found: line 1
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.oldCela fonctionne même avec des noms hachés, et vous n'avez pas à modifier le fichier à la main. Utilisez le même nom que celui avec lequel vous vous connectez. Certaines configurations demandent plus d'un appel :
ssh-keygen -R 203.0.113.10
ssh-keygen -R '[server]:2222'La seconde forme sert pour un serveur sur un port autre que 22.
Se reconnecter et comparer
ssh user@serverThe authenticity of host 'server (203.0.113.10)' can't be established.
ED25519 key fingerprint is: SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?Comparez, ou mieux, collez à cette invite l'empreinte que vous avez obtenue depuis la console. ssh les compare alors pour vous, et redemande si elles ne correspondent pas.
Pourquoi pas StrictHostKeyChecking=no
C'est le conseil que vous trouverez le plus souvent, et il supprime complètement la protection. Nous l'avons essayé face à une clé modifiée. Il affiche encore l'avertissement, puis continue :
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.La connexion par clé est quand même passée : vous travaillez donc sur un serveur que vous n'avez pas vérifié, et tout ce que vous y saisissez ou copiez peut parvenir à un attaquant. Définir UserKnownHostsFile=/dev/null fait un mal comparable : rien n'est jamais mémorisé, donc rien ne peut jamais être vérifié.
Pour les scripts qui rencontrent de nouveaux hôtes, utilisez StrictHostKeyChecking=accept-new. Il enregistre les clés des nouveaux hôtes et refuse toujours une clé modifiée, comme nous l'avons confirmé. Voir known_hosts expliqué.
Pour les scripts et la CI qui s'arrêtent sur une seule ligne, voir Host key verification failed dans les scripts et la CI.
Ne plus voir cet avertissement pour les changements prévus
- Quand vous reconstruisez un serveur, restaurez ses anciennes clés d'hôte depuis votre sauvegarde sécurisée, si votre politique le permet.
- Pour un groupe de machines derrière un même nom, utilisez des certificats d'hôte, afin que les clients fassent confiance à une autorité plutôt qu'à chaque clé.
- Pour faire une rotation des clés, ajoutez d'abord la nouvelle clé et laissez les clients l'apprendre avec
UpdateHostKeys, puis seulement ensuite retirez l'ancienne.
Questions
Suffit-il de lancer ssh-keygen -R ?
Seulement après avoir confirmé la nouvelle empreinte par un autre canal. La commande retire l'avertissement, pas sa cause, et peut donc à elle seule masquer une attaque.
Pourquoi l'avertissement apparaît-il après la réinstallation du serveur ?
Une réinstallation crée en général de nouvelles clés d'hôte, donc la clé ne correspond plus à celle enregistrée dans known_hosts. Comparez la nouvelle empreinte depuis la console, puis supprimez l'ancienne entrée.
StrictHostKeyChecking=accept-new permet-il de passer cet avertissement ?
Non. accept-new enregistre seulement les clés des hôtes jamais vus. Une clé modifiée reste refusée.
Sources
- ssh(1), vérification des clés d'hôte
- ssh_config(5), StrictHostKeyChecking
- ssh-keygen(1), manuel OpenBSD
- Dépanner la connexion à une instance EC2 Linux, AWS