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é.

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

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

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 :

- 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
- Consultez les journaux du serveur : Vérifier les enregistrements de maintenance ou les journaux de modifications pour l'activité récente
- Contactez votre hébergeur : Si vous utilisez des services cloud, vérifiez si la maintenance a eu lieu
- Utilisez un canal sécurisé : Si possible, connectez-vous via un réseau sécurisé connu pour vérifier l'empreinte digitale
- 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.
- Ouvrez votre terminal.
- 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.

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 :
- Presse Touche Windows + R.
- Taper %USERPROFILE%\.ssh et appuyez sur Entrer.
- Ouvrez le hôtes_connus fichier avec le Bloc-notes.
- 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.
- Ouvrez l'éditeur de registre (appuyez sur Touche Windows + R, taper regedit, et frappe Entrer).
- Accédez à : HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- Recherchez l'entrée qui correspond au nom d'hôte ou à l'adresse IP de votre serveur.
- Faites un clic droit dessus et sélectionnez Supprimer.

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.
- Ouvrez votre terminal.
- Taper nano ~/.ssh/known_hosts et appuyez sur Entrer.
- Recherchez le numéro de ligne mentionné dans votre message d'erreur.
- 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.

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.

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 |

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.