Comment corriger l'erreur « L'identification de l'hôte distant a changé » en SSH ?

L'avis L'IDENTIFICATION DE L'HÔTE DISTANT A CHANGÉ Ce message apparaît lorsque le client SSH détecte que la clé d'identité du serveur ne correspond pas à celle enregistrée pour cette destination. Cela peut se produire après la reconstruction d'un serveur ou la réattribution d'une adresse IP, mais aussi si vous vous connectez à une autre machine.

La solution consiste à vérifier la nouvelle identité et à mettre à jour l'entrée correspondante dans known_hostsNe supprimez pas le fichier entier et ne désactivez pas les contrôles de sécurité pour faire disparaître le message.

Vérifiez l'empreinte du nouveau serveur avant de modifier known_hosts.

Lisez attentivement l'avertissement et vérifiez la destination, le type de clé, la nouvelle empreinte et le fichier contenant l'entrée conflictuelle. Assurez-vous également d'utiliser le nom, l'adresse IP et le port attendus.

Pour vérifier l'empreinte digitale, utilisez un chemin distinct de la connexion qui affiche l'avertissement : une console de fournisseur à laquelle vous avez déjà un accès autorisé, une console physique ou un administrateur identifié par un canal connu.

Sur un serveur Linux dont la clé d'hôte Ed25519 se trouve à son emplacement habituel, vous pouvez vérifier son empreinte digitale depuis cette console :

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

Comparez le résultat complet avec celui affiché par le client. Si l'avertissement concerne une clé RSA ou ECDSA, recherchez la clé publique correspondante. Son emplacement peut varier selon la configuration du serveur.

Si vous ne pouvez pas vérifier le changement, n'acceptez pas la nouvelle identité. Veuillez demander confirmation à l'administrateur ou au fournisseur avant de poursuivre.

Que signifie « L'IDENTIFICATION DE L'HÔTE DISTANT A CHANGÉ » ?

Dans une utilisation typique d'OpenSSH, le client stocke les clés publiques des serveurs connus et les vérifie lors des connexions suivantes. empreinte digitale Il s'agit d'un résumé d'une clé, utilisé pour faciliter sa comparaison.

Ces clés permettent d'identifier le serveur et sont différentes de vos clés personnelles. Par conséquent, modifier votre mot de passe ou générer une nouvelle clé utilisateur ne résoudra pas ce problème.

L'avertissement à lui seul ne prouve pas qu'une attaque est en cours, mais il vous empêche de considérer l'identité précédente comme valide. L'ignorer pourrait vous amener à faire confiance à une machine qui usurpe l'identité du destinataire prévu.

Quels changements légitimes peuvent déclencher l'avis ?

Vérifiez si l'une de ces situations s'est produite :

• Reconstruction ou réinstallation : Le serveur a peut-être généré de nouvelles clés.
• Remplacement de la machine : Un autre serveur a peut-être reçu la même adresse IP.
• Rotation des clés : L'administrateur a peut-être remplacé les clés d'hôte.
• Changement de destination : Un nom DNS, un alias ou une adresse IP locale peut pointer vers un autre ordinateur.

Sur les plateformes cloud, la reconstruction d'une instance ou la réutilisation d'une adresse IP peut provoquer ce conflit. Malgré cela, La modification administrative doit s'accompagner d'une vérification des nouvelles empreintes digitales..

Une mise à jour système n'entraîne pas forcément un changement de mot de passe. Si personne ne remarque la modification, vérifiez la destination avant de modifier les informations enregistrées.

Supprimez uniquement l'ancienne entrée de la destination vérifiée.

Une fois l'identité vérifiée, exécutez la commande dans le périphérique client qui affiche la notificationen utilisant la destination correspondante :

ssh-keygen -R servidor.ejemplo.com

Si vous vous connectez via une adresse IP, utilisez cette adresse IP :

ssh-keygen -R 203.0.113.10

Pour un port autre que le port habituel, indiquez la destination entre parenthèses et le port :

ssh-keygen -R "[servidor.ejemplo.com]:2222"

Cette commande supprime les clés enregistrées pour cette destination dans le fichier hosts correspondant. Elle ne vérifie pas la nouvelle clé et ne modifie pas les clés du serveur.

Ne supprimez pas les entrées provenant d'autres appareils. Si vous alternez entre le nom et l'adresse IP, vérifiez lequel est concerné par l'avertissement avant de modifier les deux.

Où se trouve le fichier known_hosts sous Windows, macOS et Linux ?

Dans une configuration client OpenSSH typique, vous trouverez le fichier utilisateur aux emplacements suivants :

• Linux et macOS : ~/.ssh/known_hosts.
• OpenSSH sous Windows : %USERPROFILE%\.ssh\known_hosts.

Le chemin indiqué dans l'avertissement est la référence à vérifier. Il peut s'agir d'une configuration personnalisée ou d'un fichier global géré par votre organisation.

Pour rechercher une entrée, même si le nom est stocké à l'aide d'un hachage, utilisez :

ssh-keygen -F servidor.ejemplo.com

Si l'invite pointe vers un fichier différent, vous pouvez le spécifier avec -f. Par exemple:

ssh-keygen -R servidor.ejemplo.com -f "/ruta/indicada/known_hosts"

Les applications utilisées par d'autres clients, comme PuTTY, peuvent établir une relation de confiance avec les serveurs d'une manière différente. Cette procédure est gérée par OpenSSH.

Reconnectez-vous et comparez l'empreinte avant d'accepter.

Répétez la connexion avec le nom et le port corrects :

ssh [email protected]

Ou, si vous utilisez un port personnalisé :

ssh -p 2222 [email protected]

Dans la configuration habituelle, SSH demandera une confirmation pour la nouvelle clé. N'acceptez que si leur empreinte digitale correspond à celle que vous avez vérifiée.Si la correspondance est impossible, interrompez la connexion.

Si le conflit persiste, vérifiez si vous avez modifié le bon fichier, si vous vous connectez avec un autre utilisateur local ou si la configuration utilise un alias de clé d'hôte. Dans les environnements gérés, demandez une mise à jour du registre de confiance à votre administrateur.

Ce qu'il ne faut pas faire pour supprimer l'avertissement

Ne supprimez pas tout known_hostsVous perdriez les références d'identité des autres serveurs. De plus, n'utilisez pas StrictHostKeyChecking=no de manière générale, car cela réduit le nombre de contrôles ayant détecté le changement.

ssh-keyscan Cela permet d'obtenir les clés présentées par une destination, mais ne prouve pas qu'elles appartiennent au serveur légitime. Ajouter directement sa sortie à la liste des hôtes connus sans vérification ne fait qu'aggraver le problème de confiance.

Pour une rotation planifiée, le responsable peut étudier des mécanismes tels que : UpdateHostKeysCela vous permet d'obtenir des clés supplémentaires à partir d'une connexion déjà authentifiée. Toutefois, cela ne remplace pas la vérification d'un changement inattendu.