50% de réduction toutes les offres, durée limitée. À partir de $2.48/mo
10 min restantes
Sécurité et réseau

Avertissement : l'identification de l'hôte distant a changé et comment corriger ce problème

Rexa Cyrus By Rexa Cyrus 10 min de lecture Mis à jour il y a 56 jours
Fenêtre de terminal affichant un message d'avertissement SSH au sujet du changement d'identification de l'hôte distant, avec titre du guide de correction et marque Cloudzy sur fond sarcelle foncé.

SSH est un protocole réseau sécurisé qui crée un tunnel crypté entre les systèmes. Il reste populaire auprès des développeurs qui ont besoin d'un accès à distance aux ordinateurs sans avoir besoin d'une interface utilisateur graphique. Bien que SSH existe depuis des décennies et ait servi de manière fiable d’innombrables utilisateurs, il peut encore être affecté par certaines erreurs.

Beaucoup de ces erreurs sont désormais bien connues dans la communauté SSH et leurs solutions de contournement sont largement documentées. Ceux-ci incluent incompatibilité du pare-feu, Problèmes d'injection de clé publique SSH, Problèmes de mode clé du fichier SSH, et l'erreur « Avertissement : l'identification de l'hôte distant a changé ».

Cette erreur se produit sur tous les principaux systèmes d'exploitation, notamment Windows, Linux et macOS. La source du problème peut être un problème de sécurité légitime plutôt qu’un simple problème technique. Dans cet article, nous expliquerons pourquoi cela se produit, ce que cela signifie pour la sécurité de votre connexion SSH et comment le résoudre sur chaque plate-forme majeure.

Qu'est-ce qui déclenche l'avertissement : l'identification de l'hôte distant a changé (et devriez-vous vous inquiéter ?)

Le message « Avertissement : l'identification de l'hôte distant a changé » apparaît lorsque la clé publique SSH stockée dans votre hôtes_connus le fichier ne correspond pas à la clé que le serveur présente actuellement. Cette inadéquation déclenche le mécanisme de sécurité intégré de SSH pour vous protéger contre les menaces potentielles.

Raisons légitimes des changements de clé d'hôte

Plusieurs raisons innocentes expliquent pourquoi la clé d’hôte d’un serveur peut changer. Parfois, vous verrez des variations telles que « La clé de l'hôte RSA a changé », en fonction du type de clé spécifique utilisé.

Infographie montrant les modifications du serveur qui modifient les clés d'hôte SSH, y compris les mises à niveau du système d'exploitation, les reconstructions de serveur, la restauration des sauvegardes, la migration physique vers virtuelle et les réinitialisations de la configuration SSH.
Modifications liées au serveur :

  • Le système d'exploitation du serveur a été réinstallé ou mis à niveau
  • Le serveur a été reconstruit ou restauré à partir d'une sauvegarde
  • La configuration SSH du serveur a été réinitialisée
  • La machine physique ou virtuelle a été remplacée
  • Migration du serveur vers du nouveau matériel

Modifications de la configuration réseau :

  • Les fournisseurs de cloud recyclent les adresses IP au fil du temps ou vos itinéraires de connexion via un équilibreur de charge.
  • DHCP a réattribué une adresse IP à une autre machine
  • L'adresse IP d'un serveur mis hors service a été attribuée à un nouveau système
  • Les enregistrements DNS ont été mis à jour pour pointer vers un autre serveur

Diagramme de réseau montrant un serveur DHCP attribuant des adresses IP dynamiques aux machines virtuelles, avec la mise hors service et la réémission du serveur provoquant des conflits de clés d'hôte SSH.

Actions de gestion clés :

  • Les administrateurs système ont régénéré manuellement les clés d'hôte à des fins de sécurité
  • Le logiciel du serveur SSH a été réinstallé
  • Les politiques de sécurité nécessitaient une rotation des clés

Il est important de reconnaître que les modifications du mot de passe utilisateur n’affectent pas les clés de l’hôte. Ceux-ci représentent des mécanismes d’authentification distincts. Les clés d'hôte ne changent que lorsque le serveur lui-même ou sa configuration SSH est modifié.

Quand prendre l’avertissement au sérieux

Bien que de nombreuses modifications de clé d'hôte soient légitimes, cela pourrait indiquer une véritable menace pour la sécurité. Vous devriez vous inquiéter si :

  • Vous n’avez apporté aucune modification au serveur et n’avez connaissance d’aucune maintenance planifiée
  • Vous ne pouvez pas vérifier la raison du changement de clé auprès de l'administrateur du serveur
  • Le serveur est accessible via des réseaux publics ou des connexions non fiables
  • Vous vous connectez à des systèmes de production ou à des serveurs contenant des données sensibles


Écran partagé comparant les modifications SSH légitimes affichées en vert avec des scénarios de menaces de sécurité en rouge, avec un personnage encapuchonné représentant des attaques de l'homme du milieu.
Les attaques de l’homme du milieu, bien que relativement rares, se produisent. Dans de telles attaques, un adversaire se positionne entre votre ordinateur et le serveur légitime, interceptant tout le trafic.

Erreur humaine et l'ingénierie sociale représentent 68 % des failles de sécurité, ce qui rend la vigilance essentielle. Vous pouvez protéger davantage vos systèmes en vous renseignant sur prévention des attaques par force brute.

Des statistiques récentes d'IBM montrent que le coût moyen mondial d'un violation de données était de 4,44 millions de dollars en 2025, avec des délais de détection en moyenne de huit mois. Cela démontre pourquoi le mécanisme de vérification de la clé hôte de SSH existe et pourquoi vous ne devez jamais ignorer ces avertissements sans enquête.

Comment vérifier si l'avertissement est sûr

Avant de procéder à la résolution du problème, suivez ces étapes de vérification :

Organigramme montrant cinq méthodes de vérification pour confirmer les modifications légitimes de la clé d'hôte SSH, y compris la consultation de l'équipe, le contact du fournisseur d'hébergement, les canaux sécurisés et la comparaison des empreintes digitales.

  1. Vérifiez auprès de votre équipe : Si vous partagez l'accès au serveur, demandez à vos collègues s'ils ont apporté des modifications
  2. Consultez les journaux du serveur : Vérifier les enregistrements de maintenance ou les journaux de modifications pour l'activité récente
  3. Contactez votre hébergeur : Si vous utilisez des services cloud, vérifiez si la maintenance a eu lieu
  4. Utilisez un canal sécurisé : Si possible, connectez-vous via un réseau sécurisé connu pour vérifier l'empreinte digitale
  5. Comparez les empreintes digitales : Certains fournisseurs d'hébergement affichent les empreintes SSH actuelles dans leurs panneaux de contrôle

Si vous pouvez confirmer que le changement de clé était légitime, vous pouvez procéder en toute sécurité à la suppression de l'ancienne clé et à l'acceptation de la nouvelle.

Si vous souhaitez éviter la réattribution dynamique des adresses IP ou les conflits de clés d'hôte, l'infrastructure que vous choisissez joue un rôle important.

Cloudzy fournit Hébergement VPS SSH avec des adresses IP statiques dédiées. Vous utilisez des processeurs AMD Ryzen 9 avec stockage NVMe pour une exécution instantanée des commandes. Notre réseau atteint 40 Gbit/s sur plus de 12 sites dans le monde. De plus, nous incluons une protection DDoS gratuite pour assurer la sécurité de votre connexion.

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

La solution est simple : supprimez l’ancien enregistrement de clé de votre système. Cela efface la discordance et vous permet d'enregistrer la nouvelle clé lors de votre prochaine connexion. Consultez notre guide sur Clients SSH pour plus d'outils.

De plus, vous pouvez le faire avec une seule commande ou en modifiant le fichier manuellement.

Méthode 1 : la ligne de commande (la plus rapide)

Cette méthode fonctionne pour macOS, Linux et Windows 10+ (en utilisant OpenSSH). C'est le moyen le plus rapide de résoudre l'erreur. Pour plus d'informations, vous pouvez lire le page de manuel de ssh-keygen

  1. Ouvrez votre terminal.
  2. Exécutez cette commande (remplacez nom d'hôte avec l’IP ou le domaine de votre serveur) : 
ssh-keygen -R hostname
This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

Si vous préférez un éditeur visuel, vous pouvez supprimer la clé vous-même. Le message d'erreur vous indique généralement exactement le numéro de ligne à supprimer.

Ouvrez votre terminal et éditez le fichier avec Nano:

nano ~/.ssh/known_hosts

Recherchez la ligne de votre message d'erreur. Supprimez-le, puis appuyez sur Ctrl+X et Y pour sauvegarder.

Fenêtre du terminal macOS affichant l'éditeur de texte nano ouvert avec le fichier known_hosts, mettant en évidence la ligne à supprimer avec les étapes numérotées et les instructions d'enregistrement affichées.

Solution pour Windows

Les utilisateurs Windows utilisent généralement soit le client OpenSSH intégré, soit PuTTY.

Option 1 : Windows OpenSSH (Windows 10/11)

Sous Windows 10 et 11, OpenSSH est une fonctionnalité facultative. Ajoutez-le via Paramètres > Applications > Fonctionnalités facultatives. Le serveur 2025 inclut le client, mais vous devez l'activer.

Si vous utilisez PowerShell ou l'invite de commande, le ssh-keygen la commande de la méthode 1 fonctionne ici aussi.

Pour modifier le fichier manuellement :

  1. Presse Touche Windows + R.
  2. Taper %USERPROFILE%\.ssh et appuyez sur Entrer.
  3. Ouvrez le hôtes_connus fichier avec le Bloc-notes.
  4. Supprimez la ligne à l'origine de l'erreur et enregistrez le fichier.

Pour bien gérer les clés, consultez notre guide sur générer des clés SSH sous Windows.

Option 2 : Utiliser PuTTY

PuTTY stocke les clés dans le registre Windows plutôt que dans un fichier.

  1. Ouvrez l'éditeur de registre (appuyez sur Touche Windows + R, taper regedit, et frappe Entrer).
  2. Accédez à : HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
  3. Recherchez l'entrée qui correspond au nom d'hôte ou à l'adresse IP de votre serveur.
  4. Faites un clic droit dessus et sélectionnez Supprimer.

Commande Windows PowerShell supprimant la clé d'hôte SSH avec l'Explorateur de fichiers affichant le fichier known_hosts mis à jour et l'éditeur de registre PuTTY affichant la boîte de dialogue de confirmation de suppression pour la clé d'hôte.

Solution pour Linux

Le ssh-keygen commande que nous avons couverte Méthode 1 est le moyen standard de résoudre ce problème sous Linux. Il est rapide et pris en charge nativement.

Édition manuelle

Si vous préférez voir le contenu du fichier, vous pouvez le modifier avec un éditeur de texte comme Nano.

  1. Ouvrez votre terminal.
  2. Taper nano ~/.ssh/known_hosts et appuyez sur Entrer.
  3. Recherchez le numéro de ligne mentionné dans votre message d'erreur.
  4. Supprimez la ligne, puis appuyez sur Ctrl+X et Y pour sauvegarder.

Vous pouvez également utiliser Vim (vim ~/.ssh/known_hosts) si vous le connaissez.

Terminal Linux affichant les commandes ssh-keygen pour supprimer les clés d'hôte SSH par nom d'hôte et adresse IP, avec confirmation de réussite et exemples de fichiers known_hosts.
Un avertissement sur la désactivation des contrôles

Vous pouvez forcer la connexion de SSH sans vérification, mais cela est risqué. Il contourne la protection contre les attaques de l’homme du milieu.

Utilisez cette approche uniquement pour les tests locaux sur des réseaux de confiance. Pour macOS et Linux, tapez ceci :

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Si vous êtes sous Windows, le chemin Unix échoue. Vous devez utiliser NUL pour faire fonctionner le bypass :

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

N'exécutez pas ces remplacements sur des connexions publiques ou des serveurs en direct.

La correction des incompatibilités de clés relève d'une maintenance de routine, mais vous pouvez faire davantage pour sécuriser votre connexion. Les robots ciblent souvent le port 22 par défaut avec des attaques par force brute. Vous pouvez éviter la plupart de ce bruit de fond en changer les ports SSH sous Linux à quelque chose de moins prévisible.

Schéma d'une attaque de type man-in-the-middle sur SSH : attaquant interceptant la connexion client-serveur, clé de l'attaquant contre clé du serveur, vol de données et perte financière mis en évidence.

N'utilisez jamais cette méthode pour les serveurs de production ou sur des réseaux non fiables.

Comment empêcher le message « L'identification de l'hôte distant a changé » la prochaine fois

Bien que vous ne puissiez pas toujours empêcher les modifications légitimes de la clé d'hôte, vous pouvez minimiser les perturbations et maintenir de meilleures pratiques de sécurité.

Guide de référence rapide

Votre rôle Stratégies clés
Administrateurs système Sauvegardez les clés, documentez les modifications, utilisez des certificats et effectuez régulièrement une rotation des clés
Utilisateurs réguliers Maintenir l'inventaire, vérifier via des canaux sécurisés et surveiller les journaux
Environnement cloud 

Utilisateurs

Utilisez des noms DNS, exploitez les outils du fournisseur et implémentez l'infrastructure sous forme de code

Infographie montrant les meilleures pratiques de gestion des clés SSH : utilisez les certificats SSH, les noms DNS, l'Infrastructure as Code, sauvegardez les clés d'hôte, documentez les modifications et envisagez les hôtes bastions.

Pour les administrateurs système

Sauvegarder les clés de l'hôte : Enregistrer les clés de /etc/ssh/ avant de réinstaller le système d'exploitation. Restaurez-les ensuite pour éviter les avertissements à vos utilisateurs.

Documenter les modifications prévues : Alertez les utilisateurs avant de changer de clé et partagez les nouvelles empreintes digitales en toute sécurité. Cela leur permet de vérifier la connexion.

Utilisez des certificats SSH : Les grandes équipes doivent utiliser une autorité de certification centrale. Cela signe les clés d’hôte et supprime le besoin de vérification manuelle.

Mettre en œuvre la rotation des clés : Planifiez les modifications de votre clé d'hôte. Les mises à jour prévisibles sont plus faciles à gérer pour votre équipe que les mises à jour surprises.

Pour les utilisateurs réguliers

Tenir un inventaire : Conservez un enregistrement personnel des empreintes digitales du serveur ou utilisez la documentation sécurisée de votre équipe.

Vérifiez via hors bande : Confirmez les clés par rapport à une source fiable comme la console cloud, et non par des messages informels.

Surveiller les journaux : Vérifiez régulièrement vos journaux SSH locaux pour détecter des modèles de connexion étranges ou des erreurs répétées.

Utiliser la gestion des configurations : Utilisez les fichiers de configuration SSH pour gérer les environnements de développement dynamiques sans réduire les paramètres de sécurité.

Pour les environnements cloud dynamiques

Utiliser des noms DNS : Connectez-vous en utilisant des noms d'hôte plutôt que des adresses IP. Cela maintient la cohérence lorsque l’adresse sous-jacente change.

Tirez parti des outils cloud : Utilisez les consoles du fournisseur pour récupérer les empreintes digitales actuelles. Vérifiez les clés par rapport à ces outils avant d’accepter les modifications.

Infrastructure en tant que code : Automatisez la vérification des clés avec des outils comme Terraform. Pour les configurations avancées, vous pouvez également utiliser les proxys SSH SOCKS5.

Hôtes du Bastion : Configurez des serveurs de saut avec des clés stables. Ceux-ci agissent comme des points d’entrée sécurisés vers votre infrastructure dynamique.

Conclusion

L'« Avertissement : l'identification de l'hôte distant a changé » constitue une fonctionnalité de sécurité importante de SSH, et non une faille à ignorer. Bien que cet avertissement apparaisse souvent pour des raisons légitimes telles que la maintenance du serveur ou les modifications de configuration, il joue un rôle clé en vous protégeant contre les attaques de l'homme du milieu et les accès non autorisés.

Lorsque vous rencontrez cet avertissement, vérifiez la cause avant de continuer. Dans la plupart des cas, la solution est simple : supprimez l'ancienne clé d'hôte à l'aide des méthodes décrites pour votre système d'exploitation, puis acceptez la nouvelle clé lors de votre prochaine connexion.

En apprenant comment fonctionnent les clés d'hôte SSH et en suivant les meilleures pratiques, vous pouvez maintenir à la fois la sécurité et la commodité de vos flux de travail d'accès à distance. Pour en savoir plus sur le transfert sécurisé de fichiers, consultez copier des fichiers via SSH.

 

FAQ

Dois-je prendre garde : l'identification de l'hôte distant a sérieusement changé ?

Oui, prenez-le au sérieux. Cela signifie que l’identité du serveur a changé, ce qui pourrait signaler une attaque de l’homme du milieu ou simplement une maintenance de routine. Vérifiez toujours le changement auprès de votre administrateur ou fournisseur avant d'accepter la nouvelle clé pour garantir la sécurité.

Quelle est la cause de l'avertissement : l'identification de l'hôte distant a changé ?

Cet avertissement se produit lorsque l’empreinte digitale actuelle du serveur ne correspond pas à celle de votre fichier known_hosts. Les causes courantes incluent les réinstallations du système d'exploitation, les réattributions d'adresses IP ou les réinitialisations de la configuration SSH. Dans de rares cas, cela indique une interception active d’une attaque de l’homme du milieu.

Cette erreur peut-elle se produire sur différents systèmes d'exploitation ?

Oui, cet avertissement affecte tous les systèmes d'exploitation utilisant SSH, notamment Windows, macOS et Linux. Cela découle de la vérification de sécurité du protocole SSH. Même si les méthodes de correction varient selon la plateforme, le déclencheur de sécurité sous-jacent reste identique sur chaque système.

Comment puis-je savoir si le changement de clé d'hôte est légitime ou s'il s'agit d'une attaque ?

Pour confirmer la légitimité, vérifiez la maintenance récente, les mises à jour du système d'exploitation ou les modifications IP. Vous devez vérifier la nouvelle empreinte digitale par rapport à une source fiable, telle que la console de votre fournisseur de cloud ou une confirmation de votre administrateur système, avant de vous connecter.

La désactivation de la vérification des clés d’hôte rendra-t-elle SSH plus pratique ?

Cela ajoute de la commodité mais supprime la sécurité. La désactivation des contrôles tue la protection contre les attaques de l'homme du milieu, laissant les connexions vulnérables. Vous ne devez utiliser ce paramètre que dans des environnements de test isolés, jamais sur des serveurs de production ou des réseaux publics impliquant des données sensibles.

À quelle fréquence les clés d’hôte SSH doivent-elles être modifiées ?

Les clés hôtes ne nécessitent généralement pas de rotation régulière. Vous ne devez généralement les modifier qu'après une reconstruction du serveur, une réinstallation du système d'exploitation ou une compromission de sécurité. Les changements fréquents perturbent les utilisateurs, alors donnez la priorité à la stabilité et à une communication claire lorsque des mises à jour sont nécessaires.

Partager

Plus d'articles du blog

Continuez la lecture.

Image de titre Cloudzy pour un guide VPN L2TP MikroTik, montrant un laptop connecté à une baie de serveurs via un tunnel numérique bleu et or lumineux, avec icônes de boucliers.
Sécurité et réseau

Configuration VPN L2TP MikroTik (avec IPsec) : guide RouterOS (2026)

Dans cette configuration VPN L2TP MikroTik, L2TP gère le tunnel tandis qu'IPsec gère le chiffrement et l'intégrité ; les associer offre une compatibilité native sans agent tiers

Rexa CyrusRexa Cyrus 9 min de lecture
Illustration du guide de dépannage de serveur DNS avec symboles d'avertissement et serveur bleu sur fond sombre pour les erreurs de résolution de noms Linux
Sécurité et réseau

Échec temporaire de résolution de noms : ce que cela signifie et comment le corriger

Sous Linux, vous pouvez rencontrer une erreur d'échec temporaire de résolution de noms en tentant d'accéder à un site, de mettre à jour des paquets ou d'exécuter des tâches nécessitant une connexion

Rexa CyrusRexa Cyrus 12 min de lecture
Comment pointer un domaine vers VPS : un guide rapide
Sécurité et réseau

Comment pointer un domaine vers VPS : un guide rapide

Faire pointer un domaine vers un serveur privé virtuel est nécessaire pour héberger des sites Web et des applications. Ce guide couvre tout ce que vous devez savoir sur la connexion de votre domaine à votre

Rexa CyrusRexa Cyrus 16 min de lecture

Prêt à déployer ? À partir de 2,48 $/mois.

Cloud indépendant, depuis 2008. AMD EPYC, NVMe, 40 Gbps. Remboursement sous 14 jours.