Problème de connexion SSH avec l'erreur "Échec de la vérification de la clé de l'hôte ..."

135

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

  

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

    
posée Navid 28.05.2011 - 13:36
la source

13 réponses

158

"La vérification de la clé de l'hôte a échoué" signifie que la clé hôte de l'hôte distant a été modifiée.

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

ssh-keygen -R hostname

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

    
réponse donnée elmicha 28.05.2011 - 15:19
la source
103

Si vous exécutez certaines situations distantes / de script où vous ne disposez pas d’un accès interactif à l’invite d’ajout d’hôte, vous pouvez contourner ce problème comme suit:

$ ssh -o StrictHostKeyChecking=no [email protected] uptime

Attention: Ajout de "something.example.com, 10.11.12.13" (RSA) à la liste des hôtes connus en permanence.

    
réponse donnée MarkHu 24.07.2013 - 02:47
la source
10

Parfois aussi, il y a une situation où vous travaillez sur une console série, puis en cochant la commande en mode prolixe, -v vous indiquera que /dev/tty n'existe pas, alors qu'il le fait.

ssh -v [email protected]

Dans ce cas, supprimez /dev/tty et créez un lien symbolique de /dev/ttyS0 à /dev/tty .

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

Comme alternative, ajoutez id_rsa.pub à l'emplacement distant, de sorte que le mot de passe n'est pas invité et que vous obtenez un accès de connexion.

    
réponse donnée Peeyush 27.05.2012 - 15:01
la source
8

Dans mon cas, cela était dû à un problème avec udev - il n'y avait pas de nœud de périphérique /dev/tty . La solution pour moi était juste:

sudo mknod -m 666 /dev/tty c 5 0
    
réponse donnée Mark 25.07.2011 - 22:28
la source
3

Eh bien, tout simplement parce que le deuxième ubuntu nécessite une connexion par clé et non par mot de passe.

Je vous suggère d’utiliser sudo dpkg-reconfigure openssh-server sur votre PC, puis il devrait fonctionner correctement. Il réinitialisera la configuration pour openssh et reviendra à 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 qu’elle a changé de manière à ne plus être reconnue. Dans ce cas, vous devrez modifier le fichier .ssh/authorized_keys pour supprimer la ligne problématique identifiant votre ubuntu.

    
réponse donnée MP0 28.05.2011 - 13:39
la source
3

Ceci est un vieux sujet et je viens juste de trouver 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 lancé et dit de lancer cette commande afin de la supprimer de la liste des hôtes. Après cela, j'ai fait ce qui suit:

ssh-copy-id HOSTNAME

Que j'ai suivi les invites à partir de là jusqu'à ce que je puisse ssh entrer dans le serveur.

    
réponse donnée Hatem Jaber 15.04.2015 - 18:09
la source
3

Sur le terminal:

ssh -o StrictHostKeyChecking=No -i YourPublicKey.pem [email protected] 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 [email protected]
    
réponse donnée Vitor Abella 27.03.2017 - 02:50
la source
2

Cela signifie que votre clé d’hôte distant a été modifiée (peut être un changement de mot de passe 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 d'hôtes sur votre PC / 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 [email protected] -p 4231                              // Try again

J'espère que cela fonctionne.

    
réponse donnée Jay Patel 14.08.2016 - 06:59
la source
1

Vous devriez changer votre clé de cette manière: À partir de votre erreur, trouvez la clé hôte modifiée pour exemple: Offenser la clé ECDSA dans /Users/user-name/.ssh/known_hosts:5 ladite 5ème clé a changé, faites ceci:

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

Remarque: vous devez être root ou avoir le privilège pour sudo.

    
réponse donnée Amir.A.G 13.03.2016 - 16:22
la source
1

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

ssh-keyscan -t rsa @targethost
    
réponse donnée rob brennan 06.04.2017 - 17:42
la source
0

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

    
réponse donnée H0nsu 18.10.2012 - 08:26
la source
0

Ma solution provient de cet article: La négociation d'algorithme a échoué pour SSH Secure Shell Client

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, veuillez essayer celle-ci. Si celui-ci ne fonctionne pas aussi bien, veuillez en essayer d'autres.

    
réponse donnée Frank Puk 06.04.2017 - 19:01
la source
0

Désactivez simplement la vérification stricte de la clé d’hôte dans votre ~ / .ssh / config:

Host *
StrictHostKeyChecking no
    
réponse donnée Timo 26.04.2018 - 17:27
la source

Lire d'autres questions sur les étiquettes