Linux : résoudre “RSA host key differs from IP”

Lors d’un passage en mode rescue, d’une réinstallation serveur, d’un changement d’IP, d’une rotation des clés SSH ou d’une migration d’hébergement, il arrive que SSH refuse une connexion en affichant un avertissement sur la clé d’hôte du serveur.

Dans mon cas, après un passage en mode rescue OVH/Kimsufi, j’avais ajouté temporairement une nouvelle empreinte SSH dans ~/.ssh/known_hosts. De retour sur l’installation normale, SSH se plaignait logiquement que l’empreinte associée au hostname ne correspondait plus à celle associée à l’adresse IP.

Le message ressemble à ceci :

Warning: the RSA host key for 'hostname' differs from the key for the IP address 'xxx.xxx.xxx.xxx'
Offending key for IP in /home/matt/.ssh/known_hosts:16
Matching host key in /home/matt/.ssh/known_hosts:11
Are you sure you want to continue connecting (yes/no)?Langage du code : JavaScript (javascript)

Ce n’est pas une erreur à ignorer machinalement. SSH vous dit que l’identité cryptographique du serveur ne correspond pas à ce qu’il connaît déjà. Cela peut être parfaitement légitime après une réinstallation ou un mode rescue. Mais cela peut aussi signaler une mauvaise IP, un DNS erroné, un proxy inattendu ou une interception.

OpenSSH conserve les clés d’hôtes déjà rencontrées dans ~/.ssh/known_hosts. La page de manuel ssh précise que ce fichier contient la liste des clés d’hôtes pour les serveurs auxquels l’utilisateur s’est déjà connecté. Voir la page de manuel ssh.

Codeable: trouvez les meilleurs développeurs WordPress

Pourquoi SSH affiche cette erreur ?

Quand vous vous connectez à un serveur SSH pour la première fois, votre client enregistre l’empreinte de la clé d’hôte du serveur dans known_hosts. Cette clé sert à identifier le serveur lors des connexions suivantes.

À la connexion suivante, SSH compare :

le nom d’hôte demandé ;
l’adresse IP résolue ;
la clé d’hôte présentée par le serveur ;
les entrées déjà enregistrées dans known_hosts.

Si le hostname et l’IP ne pointent pas vers la même clé d’hôte enregistrée, OpenSSH affiche un avertissement. C’est précisément le cas de l’erreur the RSA host key differs from the key for the IP address.

Les causes les plus fréquentes sont :

serveur réinstallé ;
serveur démarré en mode rescue ;
changement d’adresse IP ;
DNS qui pointe vers une autre machine ;
IP réattribuée à un autre serveur ;
clés SSH régénérées côté serveur ;
ancien hostname conservé dans known_hosts ;
entrée IP et entrée hostname contradictoires ;
plusieurs serveurs derrière un même nom ou une même IP ;
ancienne entrée globale dans /etc/ssh/ssh_known_hosts.

Le message n’est donc pas “SSH est pénible”. Le message est plutôt “je ne reconnais pas exactement la machine à laquelle tu me demandes de parler”. Et, pour un client SSH, c’est plutôt une qualité.

Ne répondez pas “yes” trop vite

Si vous savez exactement pourquoi la clé a changé, par exemple après une réinstallation ou un passage temporaire en rescue, vous pouvez nettoyer l’ancienne entrée et accepter la nouvelle clé.

En revanche, si vous n’avez pas changé le serveur, pas régénéré les clés, pas modifié le DNS et pas demandé d’intervention côté hébergeur, arrêtez-vous. Vérifiez d’abord l’IP, le DNS et l’empreinte côté serveur ou panneau d’hébergement.

Le réglage StrictHostKeyChecking existe pour contrôler le comportement du client SSH face aux hôtes inconnus ou aux clés modifiées. OpenSSH documente cette option dans la configuration du client SSH. Voir la page de manuel ssh_config.

Le plus lu : HADOPI : le gouvernement contre-attaque

Évitez les contournements du type StrictHostKeyChecking=no pour “faire passer” une connexion sensible. C’est pratique dans certains environnements jetables, mais ce n’est pas la bonne réponse pour administrer un serveur de production.

Kinsta: Premium Managed WordPress hosting

Solution rapide : supprimer l’ancienne clé avec ssh-keygen -R

La solution propre consiste à supprimer l’ancienne entrée du fichier known_hosts, puis à se reconnecter pour accepter la nouvelle empreinte après vérification.

Pour retirer l’entrée associée au hostname :

ssh-keygen -R hostname

Pour retirer l’entrée associée à l’adresse IP :

ssh-keygen -R xxx.xxx.xxx.xxxLangage du code : CSS (css)

Si vous utilisez un port SSH personnalisé, utilisez le format avec crochets :

ssh-keygen -R '[hostname]:2222'
ssh-keygen -R '[xxx.xxx.xxx.xxx]:2222'Langage du code : JavaScript (javascript)

L’option -R de ssh-keygen retire toutes les clés appartenant au hostname indiqué dans un fichier known_hosts. C’est l’outil prévu pour ce nettoyage, plutôt qu’une édition manuelle hasardeuse. Voir la page de manuel ssh-keygen.

Exemple complet avec hostname et IP

Supposons que votre serveur soit accessible avec :

apollo.example.com
203.0.113.10Langage du code : CSS (css)

Nettoyez les deux entrées :

ssh-keygen -R apollo.example.com
ssh-keygen -R 203.0.113.10Langage du code : CSS (css)

Si vous utilisez un port spécifique, par exemple 2222 :

ssh-keygen -R '[apollo.example.com]:2222'
ssh-keygen -R '[203.0.113.10]:2222'Langage du code : JavaScript (javascript)

Ensuite, reconnectez-vous :

ssh matt@apollo.example.comLangage du code : CSS (css)

ou avec un port dédié :

ssh -p 2222 matt@apollo.example.comLangage du code : CSS (css)

SSH vous proposera d’enregistrer la nouvelle empreinte. Vérifiez-la avant d’accepter.

Vérifier l’empreinte avant d’accepter la nouvelle clé

Après suppression de l’ancienne entrée, SSH affichera une empreinte du type :

The authenticity of host 'apollo.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?Langage du code : PHP (php)

Vérifiez cette empreinte côté serveur, depuis la console de l’hébergeur, le mode rescue, une session existante fiable ou un accès hors bande.

Sur le serveur, affichez les empreintes des clés d’hôte :

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub

Comparez l’empreinte affichée par votre client SSH avec celle du serveur. Si elle correspond, vous pouvez accepter.

Les guides hébergeurs, comme OVHcloud, recommandent également de gérer les clés SSH de manière explicite et de comprendre quelles clés servent à l’authentification client et quelles clés identifient le serveur. Voir la documentation OVHcloud sur les clés SSH.

RSA, ED25519, ECDSA : pourquoi le message parle de RSA ?

L’ancien message parle de clé RSA parce que le serveur présentait alors une clé d’hôte RSA. Les serveurs OpenSSH modernes utilisent souvent plusieurs types de clés :

ssh-ed25519 ;
ecdsa-sha2-nistp256 ;
rsa-sha2-256 ;
rsa-sha2-512 ;
plus rarement les anciens algorithmes RSA/SHA-1.

Dans un dépannage moderne, vous pouvez donc voir une erreur similaire avec ED25519, ECDSA ou RSA. Le principe reste identique : l’entrée enregistrée dans known_hosts ne correspond plus à la clé d’hôte présentée par le serveur.

Inspecter known_hosts avant suppression

Pour voir les entrées connues pour un hostname :

ssh-keygen -F hostname

Pour une IP :

ssh-keygen -F xxx.xxx.xxx.xxxLangage du code : CSS (css)

Pour un port personnalisé :

ssh-keygen -F '[hostname]:2222'Langage du code : JavaScript (javascript)

Si votre fichier known_hosts est haché, les noms ne sont pas lisibles directement. C’est normal. ssh-keygen -F et ssh-keygen -R savent gérer ces entrées hachées, ce qui évite de supprimer la mauvaise ligne à la main.

Le plus lu : Installer LineageOS (Android 9.0 Pie) sur le OnePlus One

Supprimer une ligne précise de known_hosts

Le message SSH donne parfois une ligne précise :

Offending key for IP in /home/matt/.ssh/known_hosts:16

Vous pouvez supprimer cette ligne manuellement, mais ssh-keygen -R reste préférable. Si vous devez vraiment supprimer la ligne 16 :

sed -i.bak '16d' ~/.ssh/known_hostsLangage du code : JavaScript (javascript)

Cette commande crée une sauvegarde :

~/.ssh/known_hosts.bakLangage du code : JavaScript (javascript)

Encore une fois, privilégiez plutôt :

ssh-keygen -R hostname
ssh-keygen -R xxx.xxx.xxx.xxxLangage du code : CSS (css)

C’est moins spectaculaire, mais moins risqué. Et les fichiers SSH aiment beaucoup moins l’édition au scalpel après minuit.

Vérifier le DNS avant de nettoyer known_hosts

Avant d’accepter une nouvelle clé, vérifiez que le hostname pointe bien vers l’IP attendue :

dig +short hostname

Ou :

getent hosts hostname

Comparez avec l’IP du serveur dans votre panel hébergeur.

Si le DNS pointe vers une mauvaise IP, ne nettoyez pas known_hosts pour forcer la connexion. Corrigez d’abord le DNS ou connectez-vous directement à la bonne IP.

Précharger proprement une clé avec ssh-keyscan

Dans un script ou un environnement automatisé, vous pouvez récupérer la clé publique d’un serveur avec ssh-keyscan, puis l’ajouter à known_hosts.

ssh-keyscan -H hostname >> ~/.ssh/known_hostsLangage du code : JavaScript (javascript)

Avec un port personnalisé :

ssh-keyscan -H -p 2222 hostname >> ~/.ssh/known_hostsLangage du code : JavaScript (javascript)

Mais attention : ssh-keyscan récupère ce que le serveur distant présente au moment de la requête. Il ne prouve pas, à lui seul, que vous parlez au bon serveur. Pour un déploiement sensible, comparez l’empreinte avec une source de confiance.

Cas mode rescue OVH, Kimsufi ou serveur réinstallé

En mode rescue, votre serveur peut démarrer sur un système temporaire avec ses propres clés SSH. Votre client voit alors une identité différente pour le même hostname ou la même IP.

Scénario classique :

le serveur normal a une clé d’hôte A ;
le mode rescue présente une clé d’hôte B ;
vous acceptez temporairement B ;
vous redémarrez sur le système normal ;
SSH retrouve A, mais known_hosts contient aussi B pour la même IP ;
OpenSSH affiche un avertissement.

Dans ce cas, nettoyez les entrées du hostname et de l’IP :

ssh-keygen -R hostname
ssh-keygen -R xxx.xxx.xxx.xxxLangage du code : CSS (css)

Puis reconnectez-vous et vérifiez l’empreinte du système normal.

Fichier utilisateur et fichier global known_hosts

Les clés connues peuvent se trouver dans plusieurs fichiers :

~/.ssh/known_hosts
/etc/ssh/ssh_known_hostsLangage du code : JavaScript (javascript)

Le premier est propre à l’utilisateur courant. Le second est global au système.

Si vous nettoyez ~/.ssh/known_hosts mais que l’erreur persiste, cherchez aussi dans le fichier global :

ssh-keygen -F hostname -f /etc/ssh/ssh_known_hosts
ssh-keygen -F xxx.xxx.xxx.xxx -f /etc/ssh/ssh_known_hosts

Pour supprimer une entrée dans un fichier spécifique :

sudo ssh-keygen -R hostname -f /etc/ssh/ssh_known_hosts
sudo ssh-keygen -R xxx.xxx.xxx.xxx -f /etc/ssh/ssh_known_hosts

OpenSSH utilise ces fichiers pour comparer les clés d’hôtes connues et détecter les changements inattendus. La page de manuel ssh documente notamment ~/.ssh/known_hosts et les listes globales de clés connues. Voir la page de manuel ssh.

Le plus lu : Android : ma mésaventure avec Kies et ses mises à jour

Éviter que le problème revienne

Pour éviter les conflits fréquents dans known_hosts :

utilisez un hostname stable par serveur ;
évitez de réutiliser la même IP pour plusieurs machines sans nettoyer les anciennes entrées ;
ne conservez pas les clés rescue comme si elles étaient permanentes ;
vérifiez le DNS après une migration ;
documentez les empreintes SSH des serveurs de production ;
utilisez un port explicite dans les commandes si vous avez plusieurs SSH derrière une même IP ;
préchargez les clés connues dans les environnements automatisés.

Sur une infrastructure plus large, vous pouvez aussi utiliser une autorité de certification SSH pour signer les clés d’hôtes. C’est plus lourd à mettre en place, mais plus propre que de gérer manuellement des dizaines ou centaines d’empreintes dans known_hosts.

Commandes récapitulatives

Voir l’entrée connue pour un hostname :

ssh-keygen -F hostname

Voir l’entrée connue pour une IP :

ssh-keygen -F xxx.xxx.xxx.xxxLangage du code : CSS (css)

Supprimer l’entrée du hostname :

ssh-keygen -R hostname

Supprimer l’entrée de l’IP :

ssh-keygen -R xxx.xxx.xxx.xxxLangage du code : CSS (css)

Supprimer une entrée avec port personnalisé :

ssh-keygen -R '[hostname]:2222'
ssh-keygen -R '[xxx.xxx.xxx.xxx]:2222'Langage du code : JavaScript (javascript)

Afficher les empreintes côté serveur :

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub

Vérifier le DNS :

dig +short hostname
getent hosts hostname

Résumé rapide

Si SSH affiche :

Warning: the RSA host key for 'hostname' differs from the key for the IP address 'xxx.xxx.xxx.xxx'Langage du code : JavaScript (javascript)

et que vous savez pourquoi la clé a changé, supprimez les anciennes entrées :

ssh-keygen -R hostname
ssh-keygen -R xxx.xxx.xxx.xxxLangage du code : CSS (css)

Puis reconnectez-vous :

ssh user@hostnameLangage du code : CSS (css)

Avant d’accepter la nouvelle clé, comparez son empreinte avec celle du serveur :

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

Si vous n’avez pas changé le serveur ou ses clés, ne forcez pas la connexion. Vérifiez d’abord le DNS, l’IP et l’empreinte attendue.

Conclusion

L’erreur the RSA host key differs from the key for the IP address apparaît lorsque OpenSSH trouve une incohérence entre la clé d’hôte enregistrée pour un hostname et celle enregistrée pour l’adresse IP correspondante.

La correction propre consiste à retirer l’ancienne entrée avec ssh-keygen -R, à la fois pour le hostname et pour l’IP, puis à accepter la nouvelle clé uniquement après avoir vérifié son empreinte.

Dans un contexte mode rescue, réinstallation ou migration serveur, ce comportement est normal. Dans un contexte inattendu, il mérite une vraie vérification. SSH n’est pas en train de chipoter : il vous évite peut-être de parler au mauvais serveur.