Les avertissements SSH « Host key verification failed » et « REMOTE HOST IDENTIFICATION HAS CHANGED »

Ce que c'est

La page de manuel ssh(1) indique que le client compare la clé d'hôte présentée par le serveur à l'entrée enregistrée pour cet hôte dans known_hosts. Si aucune entrée n'existe et que la vérification stricte est activée, ou si l'invite de confirmation ne peut pas être affichée (BatchMode=yes, absence de terminal, comme dans la plupart des automatisations), le client s'interrompt avec Host key verification failed.. Si une entrée existe mais que la clé présentée en diffère, ssh affiche d'abord un avertissement volumineux et difficile à manquer, qui contient WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! ainsi qu'une ligne évoquant une possible attaque de type man-in-the-middle. Il indique le fichier et la ligne exacts où se trouve l'ancienne entrée, puis se termine par le même Host key verification failed..

Pourquoi c'est important

Le même message est produit par une véritable attaque par substitution de clé, mais aussi par plusieurs événements parfaitement ordinaires : un serveur reconstruit ou réinstallé de zéro, une IP flottante ou un répartiteur de charge qui pointe désormais vers un autre hôte, ou une machine re-provisionnée à partir d'une image qui régénère ses clés d'hôte au premier démarrage. Le texte de l'avertissement ne permet pas, à lui seul, de distinguer une attaque d'un changement d'infrastructure de routine ; c'est précisément pourquoi il n'est pas prudent de l'écarter par réflexe.

Comment l'appliquer

• Diagnostiquez avant de modifier quoi que ce soit : déterminez si l'hôte pouvait légitimement avoir une nouvelle clé. A-t-il été reconstruit, migré ou réaffecté récemment ? Comparez les dates avec les changements d'infrastructure connus.
• Vérifiez par un canal indépendant : obtenez l'empreinte de la nouvelle clé par un canal qui n'est pas la connexion SSH elle-même (l'opérateur du serveur, une fonction de la console du fournisseur cloud permettant de récupérer la clé d'un hôte, ou une valeur enregistrée par la gestion de configuration lors du provisionnement), puis comparez-la à celle que ssh indique pour la nouvelle clé proposée avant de continuer.
• Seulement une fois la nouvelle clé confirmée comme légitime : supprimez l'entrée obsolète avec ssh-keygen -R hostname, que ssh-keygen(1) décrit comme supprimant toutes les clés appartenant à l'hôte indiqué dans un fichier known_hosts (pour un port non standard, l'entrée est '[hostname]:2222' ; une adresse IP peut aussi avoir sa propre entrée). Reconnectez-vous ensuite et acceptez la nouvelle clé.
• Dangereux : définir systématiquement ssh -o StrictHostKeyChecking=no, ou contourner l'invite par script, comme réglage permanent. Cela supprime précisément la protection destinée à détecter une réelle substitution de clé. Cette option ne devrait être réservée, le cas échéant, qu'à des hôtes réellement jetables sur un réseau isolé, dont le risque a été explicitement accepté, et non servir de remède général à un désagrément. Pour un premier contact dans une automatisation, StrictHostKeyChecking=accept-new (OpenSSH 7.6+) enregistre les hôtes inconnus mais refuse toujours les clés modifiées ; pré-remplir known_hosts avec des clés vérifiées est encore préférable.

Pièges

• Considérer chaque occurrence comme banale parce qu'elle l'est « généralement » dans votre environnement : cette habitude est exactement ce sur quoi compte un attaquant qui mise sur le fait que cet avertissement soit ignoré.
• Supprimer tout le fichier known_hosts pour « repartir de zéro » au lieu de la seule ligne fautive, ce qui annule la vérification pour tous les autres hôtes auxquels vous faisiez déjà confiance.