2010-03-29 09:43:00 +0000 2010-03-29 09:43:00 +0000
181
181

Comment puis-je éviter la vérification de l'hôte de SSH pour les hôtes connus ?

Je reçois le message suivant chaque fois que j'essaie de me connecter à un serveur en SSH. Je tape “oui”, mais y a-t-il un moyen d'y parvenir ? 

The authenticity of host '111.222.333.444 (111.222.333.444)' can't be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)?
Source

Réponses (8)

254
254
254
2010-03-29 10:53:30 +0000

Utilisez l'option -o, 

ssh -o "StrictHostKeyChecking no" user@host
```.
Source
108
108
108
2013-08-06 21:56:17 +0000

Ajouter les lignes suivantes au début de /etc/ssh/ssh_config… 

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Options :

  • Le sous-réseau Host peut être * pour permettre un accès illimité à toutes les IP.
  • Modifier /etc/ssh/ssh_config pour une configuration globale ou ~/.ssh/config pour une configuration spécifique à l'utilisateur.

Voir http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Source
28
28
28
2010-03-29 09:47:30 +0000

Vous ne devriez l'obtenir que la première fois que vous vous connectez à un nouvel hôte. Après avoir répondu yes l'hôte est stocké dans ~/.ssh/known_hosts et vous ne serez pas invité la prochaine fois que vous vous connecterez.

Notez que si ~/.ssh/known_hosts ne peut pas être écrit pour une raison quelconque (par exemple un problème de permissions) alors vous serez invité à chaque fois que vous vous connecterez.
Source
11
11
11
2010-06-08 22:29:47 +0000

Le meilleur moyen (car il ne sacrifie pas la sécurité) est de se connecter une fois à tous les ordinateurs à partir d'un seul client (vous serez invité à chaque fois, répondez toujours oui). Comme indiqué dans l'autre réponse, les clés seront alors stockées dans ~/.ssh/known_hosts. Copiez ensuite ce fichier sur chaque ordinateur client auquel vous voudrez peut-être vous connecter plus tard (éventuellement pour chaque compte utilisateur que vous utilisez). Tous ces comptes “connaîtront” alors les ordinateurs, d'où l'absence d'invite.

L'avantage par rapport à la simple désactivation de l'invite est que SSH peut réellement vérifier s'il y a une attaque MITM.
Source
1
1
1
2015-07-11 23:20:24 +0000

Si vous souhaitez désactiver la confirmation, plutôt que l'authentification, vous pouvez utiliser cette option : “-o CheckHostIP=no” 

ssh -i sergeys_rsa_key.pem -o CheckHostIP=no brin@8.8.8.8
Source
0
0
0
2015-12-12 18:09:32 +0000

C'est probablement parce que votre serveur de clé ssh a changé, puisque l'IP du serveur ou le domaine est le même mais que la clé ssh ne correspond pas.

Vous devez supprimer la clé stockée dans /home/$user/.ssh/known_hosts pour éviter ce message.

Je l'ai corrigé en supprimant toutes les clés de ce fichier, donc un nouveau jeton est créé pour ce nom de domaine.
Source
0
0
0
2020-01-27 07:10:41 +0000

J'ai été confronté à un problème similaire où, malgré l'utilisation de la solution vérifiée mentionnée ci-dessus, mon ssh ne fonctionnait pas et c'était parce que le fichier __hosts connu était manquant dans le répertoire ~/.ssh/ et que le Système de Fichiers était en lecture seule. De plus, pendant l'exécution, je n'ai pas pu créer le fichier ~/.ssh/known_hosts.

Si vous rencontrez le même problème, voyez si vous pouvez écrire le fichier known_hosts dans le répertoire /tmp. La plupart du temps, l'écriture est possible même dans un système de fichiers en lecture seule.

Plus tard dans la commande ssh, vous pouvez spécifier le ssh pour lire le fichier known_hosts dans l'emplacement /tmp. 

ssh -o UserKnownHostsFile=/tmp/known_hosts -o StrictHostKeyChecking=no user_name@destination_server_ip
Source
-2
-2
-2
2018-11-09 12:14:07 +0000

Vérifiez les autorisations de votre fichier ~/.ssh/known_hosts. Les miennes étaient incorrectes quand j'ai eu ce problème. Je l'ai corrigé avec : 

chmod 0600 ~/.ssh/known_hosts
Source