SSH est un protocole réseau sécurisé qui établit un tunnel chiffré entre les systèmes. Il reste populaire auprès des développeurs qui ont besoin d'accéder à distance à des machines sans interface graphique. Bien que SSH existe depuis des décennies et ait fait ses preuves, il peut encore être affecté par certaines erreurs.
Beaucoup de ces erreurs sont bien connues dans la communauté SSH, et leurs solutions sont largement documentées. On trouve notamment : incompatibilité avec les pare-feux, problèmes d'injection de clé publique SSH, problèmes de mode de clé de fichier SSH, et l'erreur « Warning: Remote Host Identification Has Changed ».
Cette erreur apparaît sur tous les principaux systèmes d'exploitation, notamment Windows, Linux et macOS. Elle peut indiquer un problème de sécurité réel plutôt qu'un simple dysfonctionnement technique. Dans cet article, nous expliquons pourquoi elle se produit, ce qu'elle signifie pour la sécurité de votre connexion SSH, et comment la résoudre sur chaque plateforme.
Qu'est-ce qui déclenche l'avertissement « Warning: Remote Host Identification Has Changed » (et faut-il s'en inquiéter) ?
L'avertissement « Warning: Remote Host Identification Has Changed » s'affiche lorsque la clé publique SSH enregistrée dans votre fichier known_hosts ne correspond pas à la clé que le serveur présente actuellement. Cette divergence active le mécanisme de sécurité intégré de SSH pour vous protéger contre les menaces potentielles.
Raisons légitimes d'un changement de clé d'hôte
Plusieurs raisons tout à fait normales peuvent expliquer le changement de clé d'hôte d'un serveur. Vous pouvez parfois voir des variantes comme « RSA host key has changed », selon le type de clé utilisé.
Modifications côté serveur :
- Le système d'exploitation du serveur a été réinstallé ou mis à jour
- Le serveur a été reconstruit ou restauré depuis 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 un nouveau matériel
Modifications de la configuration réseau :
- Les fournisseurs cloud réattribuent les adresses IP au fil du temps, ou la connexion transite par un répartiteur de charge.
- Le DHCP a réattribué une adresse IP à une autre machine
- L'adresse IP d'un serveur désaffecté a été assignée à un nouveau système
- Les enregistrements DNS ont été mis à jour pour pointer vers un autre serveur
Actions de gestion des clés :
- Les administrateurs système ont régénéré manuellement les clés d'hôte pour des raisons de sécurité
- Le logiciel serveur SSH a été réinstallé
- Les politiques de sécurité ont imposé une rotation des clés
Il est important de comprendre que les modifications du mot de passe utilisateur n'ont aucun effet sur les clés hôtes. Ces deux éléments correspondent à des mécanismes d'authentification distincts. Les clés hôtes ne changent que lorsque le serveur lui-même ou sa configuration SSH est modifié.
Quand prendre l'avertissement au sérieux
Si de nombreux changements de clés hôtes sont légitimes, certains peuvent indiquer une véritable menace de sécurité. Soyez vigilant si :
- Vous n'avez apporté aucune modification au serveur et n'avez pas connaissance d'une 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 type homme du milieu, bien que relativement rares, existent bel et bien. Dans ce type d'attaque, un adversaire s'interpose entre votre ordinateur et le serveur légitime afin d'intercepter l'ensemble du trafic.
L'erreur humaine et l'ingénierie sociale représentent 68 % des failles de sécurité, ce qui fait de la vigilance un élément clé. Vous pouvez renforcer la protection de vos systèmes en vous renseignant sur la prévention des attaques par force brute.
Des statistiques récentes d'IBM indiquent que le coût moyen mondial d'une violation de données s'élevait à 4,44 millions de dollars en 2025, avec un délai de détection moyen de huit mois. Cela illustre pourquoi le mécanisme de vérification des clés hôtes de SSH existe et pourquoi vous ne devez jamais ignorer ces avertissements sans mener une investigation.
Comment vérifier si l'avertissement est sans danger
Avant de résoudre le problème, effectuez ces vérifications :
- Consultez votre équipe : Si vous partagez l'accès au serveur, demandez à vos collègues s'ils ont effectué des modifications
- Examinez les journaux du serveur : Vérifiez les historiques de maintenance ou les journaux des modifications pour toute activité récente
- Contactez votre hébergeur : Si vous utilisez des services cloud, vérifiez si une 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
- Comparer les empreintes : Certains hébergeurs 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 supprimer l'ancienne clé et accepter la nouvelle en toute sécurité.
Si vous souhaitez éviter la réassignation dynamique d'IP ou les conflits de clés hôtes, le choix de l'infrastructure a une grande importance.
Cloudzy fournit Hébergement SSH VPS avec des IP statiques dédiées. Vous tournez sur des processeurs AMD Ryzen 9 avec un stockage NVMe pour une exécution instantanée des commandes. Notre réseau atteint 40 Gbps sur 12 sites répartis dans le monde. De plus, nous incluons une protection DDoS gratuite pour sécuriser votre connexion.
Comment résoudre l'erreur « Remote Host Identification Has Changed »
La solution est simple : supprimez l'ancienne entrée de clé de votre système. Cela efface le conflit et vous permet d'enregistrer la nouvelle clé à la prochaine connexion. Consultez notre guide sur Clients SSH pour plus d'outils.
Vous pouvez également 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 sur macOS, Linux et Windows 10+ (avec OpenSSH). C'est le moyen le plus rapide de résoudre l'erreur. Pour plus d'informations, consultez la page man de ssh-keygen.
- Ouvrez votre terminal.
- Exécutez cette commande (remplacez hostname par l'IP ou le domaine de votre serveur) :
ssh-keygen -R hostnameSi vous préférez un éditeur visuel, vous pouvez supprimer la clé manuellement. Le message d'erreur indique généralement le numéro de ligne exact à supprimer.
Ouvrez votre terminal et modifiez le fichier avec Nano:
nano ~/.ssh/known_hosts
Trouvez la ligne indiquée dans le message d'erreur. Supprimez-la, puis appuyez sur Ctrl + X et Y pour enregistrer.
Solution pour Windows
Les utilisateurs de Windows utilisent généralement le client OpenSSH intégré ou PuTTY.
Option 1 : OpenSSH sous Windows (Windows 10/11)
Sur Windows 10 et 11, OpenSSH est une fonctionnalité optionnelle. Ajoutez-la via Paramètres > Applications > Fonctionnalités optionnelles. Server 2025 inclut le client, mais vous devez l'activer manuellement.
Si vous utilisez PowerShell ou l'invite de commandes, la ssh-keygen commande de la Méthode 1 fonctionne également ici.
Pour modifier le fichier manuellement :
- Appuyez sur Touche Windows + R.
- Type %USERPROFILE%\.ssh et appuyez sur Enter.
- Ouvrez le fichier known_hosts fichier avec le Bloc-notes.
- Supprimez la ligne à l'origine de l'erreur et enregistrez le fichier.
Pour gérer correctement les clés, consultez notre guide sur la génération de 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 du Registre (appuyez sur Touche Windows + R, tapez regedit, puis sur Enter).
- Accédez à : HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- Trouvez l'entrée correspondant au nom d'hôte ou à l'adresse IP de votre serveur.
- Faites un clic droit dessus et sélectionnez Supprimer.
Solution pour Linux
La ssh-keygen commande présentée dans la Méthode 1 est la méthode standard pour résoudre ce problème sur Linux. Elle est rapide et nativement prise en charge.
É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.
- Type nano ~/.ssh/known_hosts et appuyez sur Enter.
- Repérez le numéro de ligne indiqué dans le message d'erreur.
- Supprimez la ligne, puis appuyez sur Ctrl + X et Y pour enregistrer.
Vous pouvez aussi utiliser Vim (vim ~/.ssh/known_hosts) si vous le maîtrisez.
Avertissement sur la désactivation des vérifications
Vous pouvez forcer SSH à se connecter sans vérification, mais c'est risqué. Cela contourne la protection contre les attaques de type man-in-the-middle.
Réservez cette approche aux 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 sur Windows, le chemin Unix ne fonctionne pas. Vous devez utiliser NUL pour que le contournement fonctionne :
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]N'utilisez pas ces options sur des connexions publiques ou des serveurs en production.
Corriger les incohérences de clés fait partie de la maintenance courante, mais vous pouvez aller plus loin pour sécuriser votre connexion. Les bots ciblent souvent le port 22 par défaut avec des attaques par force brute. Vous pouvez éviter la majeure partie de ce bruit de fond en changeant les ports SSH dans Linux pour quelque chose de moins prévisible.
N'utilisez jamais cette méthode pour des serveurs en production ou sur des réseaux non fiables.
Comment éviter le message « Remote Host Identification Has Changed » à l'avenir
Vous ne pouvez pas toujours empêcher les changements légitimes de clés d'hôte, mais vous pouvez limiter les interruptions et adopter 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 une rotation régulière des clés |
| Utilisateurs standards | Tenez un inventaire, vérifiez via des canaux sécurisés et surveillez les journaux |
| Environnement cloud
Utilisateurs |
Utilisez des noms DNS, des outils du fournisseur et mettez en place l'infrastructure en tant que code |
Pour les administrateurs système
Sauvegarder les clés d'hôte : Enregistrez les clés depuis /etc/ssh/ avant de réinstaller le système d'exploitation. Restaurez-les ensuite pour éviter les avertissements côté utilisateurs.
Documenter les modifications planifiées : Informez les utilisateurs avant de changer les clés et partagez les nouvelles empreintes via un canal sécurisé. Ils pourront ainsi vérifier la connexion.
Utiliser des certificats SSH : Les grandes équipes devraient recourir à une autorité de certification centrale. Elle signe les clés d'hôte et supprime le besoin de vérification manuelle.
Mettre en place une rotation des clés : Planifiez le renouvellement de vos clés d'hôte. Des mises à jour prévisibles sont plus faciles à gérer pour votre équipe que des changements inattendus.
Pour les utilisateurs standards
Tenir un inventaire : Conservez un enregistrement personnel des empreintes de serveurs ou utilisez la documentation sécurisée de votre équipe.
Vérifier hors bande : Confirmez les clés via une source fiable, comme la console cloud, et non via des messages informels.
Surveiller les journaux : Consultez régulièrement vos journaux SSH locaux pour détecter des schémas de connexion inhabituels ou des erreurs répétées.
Utiliser la gestion de configuration : Utilisez les fichiers de configuration SSH pour gérer les environnements de développement dynamiques sans réduire le niveau de sécurité.
Pour les environnements cloud dynamiques
Utiliser des noms DNS : Connectez-vous via des noms d'hôte plutôt que par des adresses IP. Cela garantit la cohérence lorsque l'adresse sous-jacente change.
Tirer parti des outils cloud : Utilisez les consoles de votre fournisseur pour récupérer les empreintes actuelles. Vérifiez les clés avec ces outils avant d'accepter toute modification.
Infrastructure as Code : Automatisez la vérification des clés avec des outils comme Terraform. Pour les configurations avancées, vous pouvez également utiliser les proxies SOCKS5 de SSH.
Hôtes bastions : Configurez des serveurs de rebond avec des clés stables. Ils servent de points d'entrée sécurisés vers votre infrastructure dynamique.
Conclusion
L'avertissement « Warning: Remote Host Identification Has Changed » est une fonctionnalité de sécurité essentielle de SSH, et non une anomalie à ignorer. Même s'il apparaît souvent pour des raisons légitimes - comme une maintenance serveur ou des modifications de configuration - il joue un rôle clé dans la protection contre les attaques de l'homme du milieu et les accès non autorisés.
Lorsque vous rencontrez cet avertissement, vérifiez-en la cause avant de continuer. Dans la plupart des cas, la solution est simple : supprimez l'ancienne clé d'hôte selon la méthode adaptée à votre système d'exploitation, puis acceptez la nouvelle clé lors de votre prochaine connexion.
En comprenant le fonctionnement des clés d'hôte SSH et en appliquant les bonnes pratiques, vous pouvez concilier sécurité et simplicité dans vos flux de travail d'accès distant. Pour en savoir plus sur le transfert de fichiers sécurisé, consultez le transfert de fichiers via SSH.
