ssh: l'authenticité de l'hôte 'hostname' ne peut pas être établie

Question

Quand je ssh à une machine, parfois, je reçois cet avertissement d'erreur et il me demande de dire "oui" ou "non". Cela cause quelques problèmes lors de l'exécution de scripts qui ssh automatiquement vers d'autres machines.

Existe-t-il un moyen de dire automatiquement "oui" ou de l'ignorer?

Answer 1

En fonction de votre client ssh, vous pouvez définir la StrictHostKeyChecking option à non sur la ligne de commande, et/ou envoyer la clé à une valeur null fichier known_hosts. Vous pouvez également régler ces options dans votre fichier de config, soit pour tous les hôtes ou pour un ensemble donné d'adresses IP ou de noms d'hôte.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

MODIFIER

@IanDunn notes, il y a des risques de sécurité à le faire. Si la ressource que vous êtes connecté à a été usurpée par un attaquant, ils pourraient rejouer sur le serveur de destination défi de retour à vous, vous tromper en pensant que vous êtes connecter à distance à des ressources alors qu'en fait, ils sont de la connexion à la ressource avec vos informations d'identification. Vous devriez examiner attentivement si c'est un risque à prendre avant de modifier votre connexion mécanisme de sauter HostKeyChecking.

De référence.

Answer 2

Vieille question, qui mérite une meilleure réponse.

Vous pouvez empêcher l'invite interactive sans désactiver StrictHostKeyChecking (ce qui est d'insécurité).

Intégrer la logique suivante dans votre script:

if [[ -z `ssh-keygen -F $IP` ]]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Il vérifie si la clé publique du serveur est en known_hosts. Si pas, il demande la clé publique du serveur et l'ajoute à l' known_hosts.

De cette façon, vous êtes exposé à Man-In-The-Middle attaque qu'une seule fois, ce qui peut être atténué par:

• s'assurer que le script se connecte première fois sur un canal sécurisé
• l'inspection des rondins ou known_hosts pour vérifier les empreintes digitales manuellement (à faire une seule fois)

Answer 3

Pour désactiver (ou la désactivation), ajoutez les lignes suivantes au début de l' /etc/ssh/ssh_config...

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

Options:

• L'Hôte de sous-réseau peuvent être * afin de permettre un accès sans restriction à toutes les adresses ip.
• Edit /etc/ssh/ssh_config pour la configuration globale ou ~/.ssh/config pour la configuration spécifique à l'utilisateur.

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

Question similaire sur superuser.com - voir http://superuser.com/a/628801/55163

Answer 4

Assurez-vous que ~/.ssh/known_hosts est accessible en écriture. Cela a réglé le problème pour moi.

Answer 5

La meilleure façon de procéder consiste à utiliser «BatchMode» en plus de «StrictHostKeyChecking». De cette façon, votre script acceptera un nouveau nom d'hôte et l'écrira dans le fichier known_hosts, mais ne nécessitera pas d'intervention oui / non.

 ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"