2012-05-05 19:05:56 +0000 2012-05-05 19:05:56 +0000
315
315
Advertisement

Comment corriger l'avertissement concernant la clé hôte ECDSA

Advertisement

J'essaie de configurer un SSH sans mot de passe sur un serveur Ubuntu avec ssh-copy-id myuser@myserver, mais j'obtiens l'erreur :

Avertissement : la clé hôte ECDSA pour “myserver” diffère de la clé pour l'adresse IP “192.168.1.123”

Qu'est-ce qui provoque cela, et comment puis-je le corriger ? J'ai essayé de supprimer le répertoire .ssh sur la machine distante et d'exécuter ssh-keygen -R "myserver" en local, mais cela ne résout pas l'erreur.

Advertisement

Réponses (13)

459
459
459
2012-05-05 20:20:21 +0000

Retirez la clé en cache pour 192.168.1.123 sur la machine locale :

ssh-keygen -R 192.168.1.123
69
69
69
2014-03-11 18:52:18 +0000

Dans mon cas, ssh-keygen -R ... n'a pas corrigé l'avertissement. J'avais des informations supplémentaires comme ceci :

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

J'ai simplement modifié manuellement ~/.ssh/known_hosts et supprimé la ligne 8 (la “clé offensante”). J'ai essayé de me reconnecter, l'hôte a été ajouté de façon permanente, et tout s'est bien passé après cela !

19
Advertisement
19
19
2014-01-16 08:12:11 +0000

Je fais beaucoup de ssh-ing entre mes ordinateurs du réseau local et mes deux comptes d'hébergement web, donc j'ai réglé toutes sortes de problèmes avec SSH, y compris les problèmes d'authentification en utilisant ssh -v pour voir où et ce qui a mal tourné.

Comme je viens de résoudre ce problème et que je ne suis pas satisfait des réponses, je voulais vraiment savoir “pourquoi” moi-même…

Le déclencheur de mon cas est : j'ai installé un nouveau système d'exploitation de serveur au travail et lors de l'installation du paquet openssh-server, un nouveau jeu de clés d'hôte a été généré sur le serveur du travail. Auparavant, tous mes serveurs étaient sous Ubuntu et cette fois, ils sont passés sous Debian (et je pense qu'il y a une différence de permissions).

Quand tous les serveurs sont sous Ubuntu et que je réinstalle un serveur, dès la première connexion SSH, je reçois ce genre d'avertissement, que je préfère à l'avertissement silencieux ci-dessus !

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Puis j'ouvre ~/. ssh/known_hosts sur l'ordinateur qui lance le ssh, je supprime cette ligne, je me reconnecte et voilà ce qui se passe :

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Ce bout de phrase, environ :11122, est le numéro de port à partir duquel j'ai routé SSH sur le pare-feu

J'ai vérifié les sauvegardes d'un ancien serveur Ubuntu et j'ai comparé avec ma nouvelle installation Debian : Donc oui, probablement, l'hôte a commencé à utiliser des clés ecdsa récemment, ce qui, d'après les changements récents d'Ubuntu, est dû à une mise à jour. Le fait qu'Ubuntu se soit éloigné du système d'exploitation linux solide comme le roc sur lequel je comptais est la raison pour laquelle j'ai installé Debian cette fois-ci.

J'ai lu un security.SE q/a sur ecdsa et j'ai déjà supprimé cette ligne de sshd_config mon nouveau serveur Debian. (et j'ai fait fonctionner service ssh restart)

7
7
7
2014-01-16 09:06:57 +0000

L'invite se produit à chaque fois car les adresses IP changent tout le temps lors de l'utilisation de l'adressage dynamique. Essayez d'utiliser une adresse IP statique afin de ne devoir ajouter la clé qu'une seule fois.

6
Advertisement
6
6
2015-05-14 18:16:42 +0000

ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.123

Ceci devrait remplacer les clés existantes sous known_hosts.old et en créer une nouvelle. Cette solution a fonctionné pour moi dans le même scénario

4
4
4
2018-03-15 12:23:28 +0000

J'ai ajouté les lignes suivantes à mon ~/.ssh/config, désactivant ainsi le contrôle strict de l'hôte pour toutes les adresses .local. (avec l'attribution d'adresses DHCP, les adresses IP de mes machines locales changent constamment)

host *.local
    StrictHostKeyChecking no

Vous recevez toujours l'avertissement, ce qui me convient.

2
Advertisement
2
2
2014-10-21 09:17:22 +0000

Utilisez-vous le même utilisateur pour vous connecter ?

Si vous êtes connecté à un PC local comme l'utilisateur John et connecté au serveur B comme l'utilisateur Adolf@B et que tout va bien, cela ne signifie pas que tout va bien si vous êtes connecté à un PC local comme l'utilisateur Jane et connecté au serveur B comme l'utilisateur Adolf@B.

Si vous voulez vous connecter au serveur B comme utilisateur Beda depuis le PC A sans mot de passe, essayez cette commande, tout depuis le PC A :

ssh-keygen -t rsa

Cette commande génère la clé et stocke la clé dans le fichier. Veuillez laisser la phrase de passe vide.

ssh Beda@B mkdir -p .ssh

Cette commande crée le répertoire, s'il n'existe pas encore. Sinon, n'imprimez pas de message d'erreur.

cd ~/.ssh

Cette commande change le répertoire en votre répertoire personnel d'utilisateur ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Cette commande imprime le fichier id_rsa. pub (votre clé publique) en authorized_keys sur le serveur.

IMPORTANT : Beda est votre nom d'utilisateur sur le serveur auquel vous vous connectez, B est l'IP de votre serveur.

Maintenant, vous pouvez vous connecter au serveur B sans mot de passe ou phrase de passe :

ssh Beda@B
1
1
1
2012-08-07 15:42:41 +0000

Question : Quelle est la cause de ce changement, … ?

  • La clé d'hôte du serveur ssh a donc changé.&nbsp ; Qu'est-ce qui a causé le changement ? &nbsp ; Il est difficile de dire .&nbsp ; Voici quelques suppositions :

  • Est-ce que sshd sur myserver a commencé à utiliser des clés ECDSA, donc c'est un nouveau type de clé ?

  • Est-ce que myserver a été récemment réinstallé ?

  • Est-ce que sshd sur myserver a été récemment réinstallé, donc une nouvelle clé d'hôte ssh a été générée ?

  • Quelqu'un a-t-il regénéré ou remplacé la clé d'hôte sshd ?

  • L'adresse IP de myserver a-t-elle changé de sorte qu'un hôte différent répond à cette adresse IP ?

Question : … et comment y remédier ?

Comme d'autres ont déjà répondu, supprimez la clé d'hôte ECDSA de myserver que votre compte a mise en cache.

1
Advertisement
1
1
2012-12-20 16:47:41 +0000

Le fil de discussion ici peut vous aider.

Essentiellement, vous voulez supprimer les clés RSA et ECDSA pour cet hôte, puis utiliser ssh-keyscan pour les remettre dans votre fichier known_hosts d'une manière qui ne causera pas ce conflit. Cela a fonctionné pour moi lorsque j'avais le même problème.

1
1
1
2017-08-25 12:43:26 +0000

Cette erreur m'a longtemps ennuyé. Pour une raison quelconque, cela faisait une différence si je faisais un

ssh host

ou un

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

puis m'indiquait la possibilité de modifier le fichier de configuration. Voir mon script https://askubuntu.com/a/949731/129227 là pour automatiser le processus.

0
Advertisement
0
0
2015-05-18 23:26:58 +0000

J'ai réglé cela sur un Chromebook en désinstallant et réinstallant Secure Shell… Ça a marché comme sur des roulettes.

0
0
0
2020-02-23 01:54:19 +0000

De mon côté, cela se produit en raison de ce que je considère comme un bogue ssh des clients plus récents (OpenSSH_7.9p1 et au-dessus), lorsqu'il essaie d'apprendre une clé de serveur ecdsa plus sûre alors qu'il existe déjà une clé de type rsa plus ancienne connue. Il présente alors ce message trompeur !

Je ne connais pas de bonne solution à ce problème, la seule solution que j'ai trouvée est de supprimer toutes les “bonnes mais anciennes clés rsa” de sorte que le client puisse réapprendre les “nouvelles clés ecdsa plus sûres”. Donc :

  1. La première étape consiste à supprimer toutes les bonnes vieilles clés RSA ( Attention ! Cela perd la protection contre le MitM ) :

  2. La deuxième étape consiste ensuite à réapprendre toutes les clés d'hôtes, ce qui doit être fait manuellement en se connectant à chaque IP à nouveau en utilisant ssh.


Voici ce que j'observe :

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp> 

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>

Essayez maintenant de vous connecter à un alias nouvellement introduit de ce même bon serveur déjà connu :

$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

Veuillez regarder l'adresse IP. C'est la même adresse IP que ci-dessus ! Il semble donc que la (bonne) clé de l'IP (connue) s'offense soudainement (ce n'est pas le cas, car le client ssh mélange deux clés incompatibles, voir ci-dessous).

Maintenant, nous essayons de le réparer :

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Essayons à nouveau :

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?

WTF ? Que s'est-il passé ici ? La nouvelle clé fraîche apprise du serveur a encore échoué ? Et le problème a même changé de camp ?!?

Non, ce n'est pas la clé, ni le serveur. Tout est correct !

C'est le client ssh qui ne vérifie pas la bonne clé ! L'entrée 45 dans known_hosts porte maintenant une clé de type ecdsa-sha2-nistp256 alors que la clé, qui a été retirée du serveur par le client, est de type rsa-sha2-512 (et donc ne peut pas correspondre à l'autre clé !).

$ sftp -v test@valentin.hilbig.de

montre :

debug1: kex: host key algorithm: rsa-sha2-512

alors que

$ sftp -v test@gcopy.net

Apparemment le client ssh a un bug quelque part ! Il ne peut pas gérer une clé hôte existant dans plus d'une variante ! Ou alors il tombe dans le piège de demander une variante obsolète d'une clé.

Comment corriger ?

Je n'en ai vraiment aucune idée. Cela ne peut probablement être corrigé qu'en amont.

Mais il existe une solution de contournement manuelle mais maladroite :

Vous devez supprimer manuellement toutes les traces de l'ancienne clé de type rsa. La clé en question est affichée dans la sortie, mais elle n'est pas directement marquée comme étant le problème :

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

vérifier :

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

donne

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

Donc ici la clé hôte matching est la clé offensante et la clé offensante est la bonne qui doit être conservée ! Donc, retirons la mauvaise clé (correspondante) :

ecdsa-sha2-nistp256
ssh-rsa

Maintenant, vérifiez à nouveau :

ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

YAY ! Le problème a finalement disparu. Mais avec plusieurs centaines d'entrées dans .ssh/known_hosts, cette “solution” devient vraiment une PITA majeure (et un cauchemar de sécurité sujet aux erreurs sur Elm Street. YMMV.)

0
Advertisement
0
0
2017-07-24 07:55:39 +0000

Voici comment supprimer l'empreinte d'un hôte connu (du fichier known_hosts) sur un OS Chrome :

Trouvez l'index de l'entrée de l'hôte en infraction dans la sortie ssh lorsque la connexion échoue. Par exemple, dans la ligne sous l'index offensif 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Ouvrez la console JavaScript (CTRL+Shift+J) de la fenêtre Secure Shell et tapez ce qui suit, en remplaçant INDEX par la valeur appropriée (par exemple 7 ) :

term_.command.removeKnownHostByIndex(INDEX);

Cette solution a été empruntée au Blog de Leo Gaggl .

Advertisement
Advertisement