J'essaie d'installer SSH sans mot de passe sur un serveur Ubuntu avec ssh-copy-id myuser@myserver, mais je reçois le message d'erreur:
Attention: la clé d'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 .sshrépertoire sur la machine distante et de l'exécuter ssh-keygen -R "myserver"localement, mais cela ne résout pas l'erreur.
Réponses:
Supprimez la clé en cache pour 192.168.1.123sur la machine locale:
ssh-keygen -R 192.168.1.123
ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsensuite, vous n'avez pas besoin de vérifier la nouvelle clé lors de la première connexion à l'hôte.
Dans mon cas ssh-keygen -R ..., l'avertissement n'a pas été corrigé. J'ai eu des informations supplémentaires comme celle-ci:
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é ~/.ssh/known_hostset supprimé manuellement la ligne 8 ("clé incriminée"). J'ai essayé de me reconnecter, l'hôte a été ajouté en permanence et tout allait bien après!
sed -e '8d' /home/myuser/.ssh/known_hosts, en remplaçant le numéro de ligne 8et le nom du fichier par ceux affichés sur votre système.
known_hosts:8fait référence à une valeur indexée à zéro ou non. Il est bon de savoir qu'il s'agit d'une cartographie 1: 1 ...
ssh-keygen -R [hostname]:2022
~/.ssh/known_hosts, je reçois le message que l'authenticité ne peut pas être établie et "Êtes-vous sûr de vouloir continuer à vous connecter". Répondre "oui" tente et échoue à se connecter. Si j'essaie de me connecter une deuxième fois, j'obtiens la même erreur de clé d'hôte ECDSA que celle avec laquelle j'ai commencé.
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 des problèmes d’authentification, qui ssh -vpermettaient de voir où et quels étaient les problèmes.
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: le nouveau système d'exploitation du serveur installé 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 les systèmes d'exploitation de mon serveur étaient Ubuntu et cette fois, Debian a été remplacé (et je suppose qu'il existe une différence nuancée d'autorisations).
Lorsque tous les systèmes d'exploitation étaient Ubuntu et que je réinstalle le système d'exploitation d'un serveur, dès le premier SSH, je reçois ce type d'avertissement, que je préfère par rapport à 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.
Ensuite, je m'ouvre ~/.ssh/known_hostssur l'ordinateur à l'origine du SSH, supprime cette ligne, me reconnecte et ceci 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 sur lequel je route SSH depuis le pare-feu
J'ai vérifié les sauvegardes d'un ancien serveur Ubuntu et comparé à 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, oui, probablement, l'hôte a commencé à utiliser des clés ecdsa récemment, ce qui, selon les modifications apportées par Ubuntu récemment, serait à l'origine d'une mise à jour. Ubuntu s’est éloigné du système d’exploitation Linux sur lequel j’avais compté, c’est pourquoi j’ai installé Debian cette fois-ci.
J'ai lu le fichier security.SE q / a sur ecdsa et j'ai déjà retiré cette ligne de sshd_configmon nouveau serveur Debian. (et couru service ssh restart)
ubuntu debian serveret vous verrez ce que je veux dire.
L'invite se produit à chaque fois car les adresses IP changent tout le temps lors de l'utilisation d'un adressage dynamique. Essayez d’utiliser une adresse IP statique afin de ne devoir ajouter la clé qu’une seule fois.
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
J'ai ajouté les lignes suivantes à mon ~ / .ssh / config, désactivant ainsi la vérification stricte de l'hôte pour toutes les adresses .local. (avec l'allocation d'adresse DHCP, les adresses ip de mes machines locales changent constamment)
host *.local
StrictHostKeyChecking no
Vous recevez toujours l'avertissement, ce qui me convient parfaitement.
Utilisez-vous le même utilisateur pour vous connecter?
Si vous êtes connecté à un PC local tel que l'utilisateur John et connecté au serveur B tel que l'utilisateur Adolf @ B et que tout va bien, cela ne signifie pas que tout va bien si vous êtes connecté à un PC local tel que l'utilisateur Jane et que vous vous connectez au serveur. B comme utilisateur Adolf @ B .
Si vous souhaitez vous connecter au serveur B en tant qu'utilisateur Beda du PC A sans mot de passe, essayez cette commande, le tout à partir du PC A :
ssh-keygen -t rsa
Cette commande génère la clé et la stocke dans le fichier. S'il vous plaît laissez la phrase secrète 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 modifie le répertoire dans le répertoire de base de votre utilisateur ./ssh.
cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'
Cette commande affiche le fichier id_rsa.pub (votre clé publique) dans authorized_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 ou phrase secrète:
ssh Beda@B
Le fil ici peut aider.
En gros, vous voulez supprimer les clés RSA et ECDSA de cet hôte, puis les utiliser ssh-keyscanpour les replacer dans votre known_hostsfichier de manière à ne pas causer ce conflit. Cela a fonctionné pour moi quand j'ai eu le même problème.
Question: Qu'est-ce qui cause ça, ...?
La clé d’hôte du serveur ssh a donc changé. Quelle est la cause du changement? C'est dur à dire. Voici quelques hypothèses:
Question: ... et comment puis-je résoudre ce problème?
Comme d’autres ont déjà répondu, supprimez la clé d’hôte ECDSA mise en cache pour myserver que votre compte a mis en cache.
Cette erreur m'a longtemps ennuyé. Pour une raison quelconque, cela ferait une différence si je ferais un
ssh host
ou
ssh host.domain
https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
m'a ensuite indiqué l'option de modifier le fichier de configuration. Voir mon script https://askubuntu.com/a/949731/129227 pour l'automatisation du processus.
CanonicalizeHostnameet CanonicalDomainséviterait la suppression et la vérification stricte rendrait ssh hôte et envisager host.domain être même.
J'ai corrigé ce problème sur un Chromebook en désinstallant et en réinstallant Secure Shell ... Cela fonctionnait à merveille.
Voici comment supprimer une empreinte digitale d'hôte connue (d'un known_hostsfichier) sur un système d'exploitation Chrome:
Recherchez l'index de l'entrée de l'hôte incriminé dans la sortie ssh en cas d'échec de la connexion. Par exemple, dans la ligne ci-dessous, l'index incriminé est 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 INDEXpar la valeur appropriée (par exemple 7 ):
term_.command.removeKnownHostByIndex(INDEX);
The ECDSA host key for server has changed. Mon moyen est de supprimer la chaîne de cache associée à propos du domaine dans~/.ssh/known_hosts. Ensuite, le SSH fonctionne.