Problème de connexion SSH avec erreur «Échec de la vérification de la clé d'hôte…»

Je peux me connecter à un autre ordinateur Ubuntu de mon réseau local via SSH. Sur les deux ordinateurs, j’ai installé openssh-server mais à partir d’un autre ordinateur Ubuntu, je ne peux pas me connecter à mon PC via SSH et j’ai eu cette erreur:

La vérification de la clé de l'hôte a échoué ...

« Vérification de la clé hôte a échoué » signifie que l' hôte clé de l'hôte distant a été changé.

SSH stocke les clés d’hôte des hôtes distants dans ~/.ssh/known_hosts. Vous pouvez soit modifier ce fichier texte manuellement et supprimer l'ancienne clé (vous pouvez voir le numéro de ligne dans le message d'erreur), soit utiliser

ssh-keygen -R hostname

De la page de manuel :

-R nom_hôte
Supprime toutes les clés appartenant à nom_hôte d'un fichier known_hosts. Cette option est utile pour supprimer les hôtes hachés.

(ce que j'ai appris de la réponse à Est-il possible de supprimer une clé d'hôte particulière du fichier Réponses_hosts de SSH? ).

Si vous exécutez certaines situations de script / à distance dans lesquelles vous ne disposez pas d'un accès interactif à la clé prompt-to-add-hostkey, procédez comme suit:

$ ssh -o StrictHostKeyChecking=no user@something.example.com uptime

Avertissement: Ajout permanent de 'quelque chose.exemple.com, 10.11.12.13' (RSA) à la liste des hôtes connus.

De plus, il arrive parfois que vous travailliez sur une console série . Par conséquent, si -vvous cochez la commande ci-dessus en mode commenté, votre présence /dev/ttyn’existera pas.

ssh -v user@hostname

Dans le cas ci-dessus, supprimez simplement /dev/ttyet créez un lien symbolique /dev/ttyS0vers /dev/tty.

rm /dev/tty
ln -s /dev/ttyS0 /dev/tty

En guise d'alternative, ajoutez-le id_rsa.pubà l'emplacement distant, afin que le mot de passe ne soit pas demandé et que vous obteniez un accès pour vous connecter.

Dans mon cas, cela était dû à un problème udev - il n’existait aucun /dev/ttynœud de périphérique. La solution pour moi était juste:

sudo mknod -m 666 /dev/tty c 5 0

Sur le terminal:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem user@example.com uptime

Le message suivant, ou similaire, apparaîtra:

Warning: Permanently added 'example.com, XX.XXX.XXX.XX' (ECDSA) to the list of known hosts.
 00:47:37 up 3 min,  0 users,  load average: 0.00, 0.00, 0.00

Ensuite, connectez-vous à votre EC2 normalement:

ssh -i YourPublickey.pem user@example.com

Eh bien, tout simplement parce que le second Ubuntu nécessite une connexion par clé et non par mot de passe.

Je vous suggère d'utiliser sudo dpkg-reconfigure openssh-serversur votre PC, et alors il devrait fonctionner correctement. Il réinitialisera la configuration pour openssh et devrait revenir à une authentification par mot de passe par défaut.

La deuxième possibilité est qu’il existe déjà une clé pour votre autre ubuntu dans votre PC et que celle-ci a changé, de sorte qu’elle n’est plus reconnue. Dans ce cas, vous devrez éditer le fichier .ssh/authorized_keyspour supprimer la ligne problématique identifiant votre Ubuntu.

C'est un vieux fil et je viens de rencontrer cette réponse, je vais juste ajouter ce que j'ai fait pour résoudre ce problème.

ssh-keygen -f "/home/USER/.ssh/known_hosts" -R HOSTNAME

Je viens de regarder le message d'erreur qu'il m'a jeté et il a dit d'exécuter cette commande afin de le supprimer de la liste des hôtes. Après cela, j'ai fait ce qui suit:

ssh-copy-id HOSTNAME

Puis j'ai suivi les instructions à partir de là jusqu'à ce que je puisse ssh dans le serveur.

Cela signifie que votre clé d'hôte distant a été modifiée (peut être un changement de mot de passe d'hôte),

Votre terminal a suggéré d'exécuter cette commande en tant qu'utilisateur root

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231

Vous devez supprimer ce nom d’hôte de la liste des hôtes sur votre ordinateur / serveur. Copiez cette commande suggérée et exécutez-la en tant qu'utilisateur root.

$ sudo su                                                            // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231   // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                               // Exist from root user

$ sudo ssh root@www.website.net -p 4231                              // Try again

J'espère que ça marche.

Vous devez modifier votre clé de la manière suivante: Trouvez dans votre erreur donnée la clé d’hôte modifiée, par exemple: Clé ECDSA incriminée dans /Users/user-name/.ssh/known_hosts:5, la cinquième clé a été modifiée, procédez comme suit:

sed -i '5d' ~/.ssh/known_hosts

Remarque: vous devez être root ou avoir des privilèges pour sudo.

vous devez mettre la clé rsa de l'hôte cible dans l'hôte source /home/user/.ssh/known_hostsen l'exécutant sur la cible

ssh-keyscan -t rsa @targethost

Peut-être avez-vous juste besoin d'entrer "oui" lorsque ssh confirme que vous souhaitez continuer à vous connecter.

Comme ci-dessous.

The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is yyy.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx' (ECDSA) to the list of known hosts.
Enter passphrase for key '/Users/ysy/.ssh/id_rsa':

Puis entrez votre mot de passe.

Veuillez faire attention à "Êtes-vous sûr de vouloir continuer à vous connecter (oui / non)? Oui ". Vous devez entrer oui, pas entrer.

Autre que désactiver strictement la vérification de la clé de l'hôte, vous pouvez également vous connecter en tapant:

ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no <username@target_machine_ip_or_domain_name>

pico ~/.ssh/known_hosts et supprimez toutes les lignes, après juste vous reconnecter et vous obtiendrez une nouvelle clé.

Ma solution provient de cet article de blog: Échec de la négociation de l'algorithme pour le client SSH Secure Shell

Vous devez modifier le fichier comme suit:

sudo nano /etc/ssh/sshd_config

Et puis ajoutez ce qui suit:

# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

En gros, vous avez essayé différentes solutions jusqu'à ce que vous en trouviez une qui puisse résoudre votre problème. Si les solutions ci-dessus ne fonctionnent pas, essayez celle-ci. Si celui-ci ne fonctionne pas aussi bien, veuillez en essayer d'autres.

Il suffit de faire "sudo vi /var/root/.ssh/known_hosts" et de supprimer la ligne contenant une clé pour un hôte auquel vous essayez de vous connecter et de vous reconnecter.

Je ne connais pas votre situation particulière, mais très probablement cette erreur est venue avec un message comme celui-ci:

my_mac:~ oivanche$ sudo ssh pi@192.168.0.45
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /var/root/.ssh/known_hosts:74
ECDSA host key for 192.168.0.45 has changed and you have requested strict checking.
Host key verification failed.

Si vous lisez le journal plus attentivement, vous constaterez que la clé obtenue auprès d'un hôte est en conflit avec une clé déjà existante. Dans ce cas, elle se trouve à la ligne 74 du fichier known_hosts root / .ssh / known_hosts: 74). Supprimez la ligne des known_hosts, enregistrez les modifications et reconnectez-vous.

chmod 666 /dev/tty 

est encore une autre solution tty - parfois, ce fichier de périphérique a des autorisations erronées.