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)?
Ajouter les lignes suivantes au début de /etc/ssh/ssh_config…
Host 192.168.0.*
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
Options :
* pour permettre un accès illimité à toutes les IP. /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
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.
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.
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.
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
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