Question Comment réparer un avertissement sur la clé hôte ECDSA


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

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

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


210
2018-05-05 19:05


origine


dans mon cas, je change le serveur (ip) lie avec le domaine, puis le The ECDSA host key for server has changed. Mon moyen est de supprimer la chaîne de cache associée sur le domaine dans ~/.ssh/known_hosts. Ensuite, le ssh fonctionne. - Ninja


Réponses:


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

ssh-keygen -R 192.168.1.123

302
2018-05-05 20:20



N'a pas fonctionné pour moi sur le serveur Debian récemment installé au travail lorsque SSHing est parti de chez moi. En outre, la réponse est plutôt laconique. - Chris K
/home/wf/.ssh/known_hosts mis à jour Contenu original conservé sous la forme /home/wf/.ssh/known_hosts.old "Avertissement: La clé de l'hôte ECDSA pour l'adresse IP 'x.x.x.x' a été ajoutée de manière permanente à la liste des hôtes connus." est affiché. et puis il semble fonctionner - Wolfgang Fahl
Vous pouvez mettre à jour la clé au lieu de la supprimer. Utilisation ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts Après cela, vous n'avez pas besoin de vérifier la nouvelle clé lors de la première connexion à l'hôte. - Alex
Pour ceux qui ne réussissent pas à le faire fonctionner: j'ai enregistré plusieurs occurrences de la même adresse IP: 1 / ladite adresse IP (xx.xx.xx.xx), domaine (tomsihap.fr), serveur vps donné par le fournisseur adresse (vpsxxx.ovh.net) ssh-keygen -R pour chacun d'eux a fait le travail. - tomsihap
Travaillé pour moi, mais la confusion pourrait provenir de quel hôte cette commande devrait-elle être exécutée? La réponse provient de celle qui a montré l'erreur. La deuxième question et réponse sont plus évidentes, mais juste au cas où: quelle adresse passer à ssh-keygen -R? L'adresse qui figure dans la déclaration d'erreur. - Russ Bateman


Dans mon cas ssh-keygen -R ... n'a pas réparé l'avertissement. J'ai eu 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 édité manuellement ~/.ssh/known_hosts et supprimé la ligne 8 (la "clé incriminée"). J'ai essayé de me reconnecter, l'hôte a été ajouté en permanence et tout allait bien après ça!


40
2018-03-11 18:52



Cela a fonctionné pour moi. Merci! - Organic Marble
Fonctionne comme un charme. Peut résoudre ce problème en une ligne avec sed -e '8d' /home/myuser/.ssh/known_hosts, en remplaçant le numéro de ligne 8 et le nom de fichier avec ceux affichés sur votre système. - Alex P. Miller


Je fais beaucoup de ssh-ing entre mes ordinateurs de réseau local et mes deux comptes d’hébergement web, alors j’ai trié toutes sortes de cotes et de terminaisons avec SSH, y compris des problèmes d’authentification en utilisant ssh -v pour voir où et quoi a mal tourné.

Ayant juste résolu ce problème et n'étant pas satisfait des réponses, je voulais vraiment savoir "pourquoi" moi-même ...

Le déclencheur de mon cas est le suivant: nouveau système d’exploitation du serveur au travail et lors de l’installation du paquetage openssh-server, un nouvel ensemble de clés d’hôte a été généré sur le serveur de travail. Auparavant, tous mes systèmes d'exploitation de serveur étaient Ubuntu et cette fois, ils sont devenus Debian (et je soupçonne qu'il existe une différence nuancée dans les autorisations).

Quand tous les systèmes d'exploitation étaient Ubuntu et que je réinstallais le système d'exploitation d'un serveur, dès le premier SSH, j'obtiens ce type 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 je m'ouvre ~ / .ssh / known_hosts sur l'ordinateur à l'origine du ssh, supprimez cette ligne, reconnectez-vous et cela se produit:

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 bit à propos de: 11122 est le numéro de port que j'achemine de SSH sur le pare-feu

J'ai vérifié les sauvegardes d'un ancien serveur Ubuntu et les ai comparées à ma nouvelle installation Debian:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

Donc, probablement, l'hôte a récemment commencé à utiliser les clés ecdsa, ce qui, sur la base des modifications apportées par Ubuntu ces derniers temps, serait responsable d'une mise à jour. L'abandon d'Ubuntu par rapport au système d'exploitation Linux solide sur lequel je comptais est la raison pour laquelle j'ai installé Debian cette fois.

Je lis un security.SE q / a sur ecdsa et ont déjà retiré cette ligne de sshd_config mon nouveau serveur Debian. (et couru service ssh restart)


14
2018-01-16 08:12



+1 pour le beau bloc de comparaison côte à côte. Pourriez-vous ajouter une URL indiquant que "le passage d'Ubuntu au système d'exploitation Linux solide" signifie? - bgoodr
@bgoodr c'est mon avis et uniquement basé sur la configuration de mon propre serveur de fichiers RAID plusieurs fois au cours des dernières années. : / Crap for answer, mais commencez à googler ubuntu debian server et vous verrez ce que je veux dire. - Chris K
@ChrisK Vous, monsieur, êtes un patron. Merci pour la réponse détaillée, mais concise. - sargas


ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Cela 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


5
2018-05-14 18:16





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, il vous suffit donc d'ajouter la clé une seule fois.


4
2018-01-16 09:06



Bon point, est-ce que j'ai raté où quelqu'un a mentionné les ips dynamiques? - Chris K


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

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

Si vous voulez vous connecter sur le serveur B en tant qu'utilisateur Beda depuis le PC UNE sans mot de passe, essayez cette commande, le tout à partir du PC UNE:

ssh-keygen -t rsa

Cette commande génère la clé et stocke la clé dans le fichier. S'il vous plaît laisser mot de passe vide.

ssh Beda@B mkdir -p .ssh

Cette commande crée le répertoire, s’ils n’existent pas déjà. Sinon, n'imprimez pas de message d'erreur.

cd ~/.ssh

Cette commande remplace le répertoire par le répertoire personnel de votre utilisateur ./ssh.

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

Cette commande imprime le fichier id_rsa.pub (votre clé publique) dans autorisé_keys sur le serveur.

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

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

ssh Beda@B

2
2017-10-21 09:17



Ou utilisez simplement ssh-copy-id pour remplir un fichier authorized_keys avec votre clé id_rsa.pub sans avoir à vous soucier de tout. - BlakBat


Le fil ici peut aider.

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


1
2017-12-20 16:47





Question: Qu'est-ce qui cause ceci, ...?

La clé de l'hôte du serveur ssh a donc été modifiée. Qu'est-ce qui a causé le changement? C'est dur à dire. Voici quelques suppositions:

  • Est-ce que sshd sur myserver a commencé à utiliser les clés ECDSA, donc c'est un nouveau type de clé?
  • Est-ce que myserver a été récemment réinstallé?
  • Sshd sur myserver a-t-il été ré-inséré récemment? Une nouvelle clé d'hôte ssh a donc été générée?
  • Quelqu'un at-il re-généré ou remplacé la clé hôte sshd?
  • L'adresse IP de myserver a-t-elle été modifiée pour qu'un autre hôte réponde à cette adresse IP?

Question: ... et comment puis-je le réparer?

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


1
2017-08-07 15:42



Bon conseil, mais ne répond pas réellement à la question. Ne tente même pas de répondre à la question. - boatcoder