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

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

Message D'Avertissement:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

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

124
demandé sur Nullpointer 2010-09-08 05:04:27

12 réponses

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

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

Modifier

Comme le note @IanDunn, cela comporte des risques de sécurité. Si la ressource à laquelle vous vous connectez a été usurpée par un attaquant, il pourrait potentiellement rejouer la destination le défi du serveur vous revient, vous faisant croire que vous vous connectez à la ressource distante alors qu'en fait, ils se connectent à cette ressource avec vos informations d'identification. Vous devriez examiner attentivement si c'est un risque approprié à prendre avant de modifier votre mécanisme de connexion pour ignorer HostKeyChecking.

Référence.

111
répondu cori 2013-09-03 01:29:27

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

Vous pouvez empêcher l'invite interactive sans désactiver StrictHostKeyChecking (ce qui n'est pas sûr).

Incorporez 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 dans known_hosts. Sinon, il demande la clé publique du serveur et l'ajoute à known_hosts.

De cette façon, vous n'êtes exposé à L'attaque de L'homme du milieu qu'une seule fois, ce qui peut être atténué par:

  • veiller à ce que le script se connecte pour la première fois sur un canal sécurisé
  • inspecter les journaux ou known_hosts pour vérifier les empreintes digitales manuellement (à faire une seule fois)
60
répondu Grzegorz Luczywo 2014-11-04 16:52:15

Pour désactiver (ou la désactivation), ajoutez 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 hôte peut être * pour permettre un accès illimité à toutes les adresses IP.
  • Modifier /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 -tu vois https://superuser.com/a/628801/55163

30
répondu Jim Fred 2017-03-20 10:04:24

Assurez-vous que ~/.ssh/known_hosts est accessible en écriture. Qu'il fixe pour moi.

14
répondu richard 2014-02-19 17:40:37

Modifiez votre fichier de configuration normalement situé à'~/.ssh/config', et au début du fichier, ajoutez les lignes ci-dessous

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

L'utilisateur défini sur your_login_user indique que ces paramètres appartiennent à your_login_user
StrictHostKeyChecking défini sur no évitera l'invite
IdentityFile est le chemin de la clé RSA

Cela fonctionne pour moi et mes scripts, bonne chance à vous.

10
répondu Carlos M G T 2015-04-16 20:13:57

La meilleure façon de procéder est d'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"
8
répondu Cory Ringdahl 2014-06-18 19:10:17

Cet avertissement est émis en raison des fonctionnalités de sécurité, Ne désactivez pas cette fonctionnalité.

Il est juste affiché une fois.

S'il apparaît toujours après la deuxième connexion, le problème est probablement en écriture dans le fichier known_hosts. Dans ce cas, vous obtiendrez également le message suivant:

Failed to add the host to the list of known hosts 

Vous pouvez le corriger en changeant le propriétaire de la modification des autorisations du fichier pour être accessible en écriture par votre utilisateur.

sudo chown -v $USER ~/.ssh/known_hosts
6
répondu Sfisioza 2015-05-27 07:17:13

En référence à la réponse de Cori, Je l'ai modifié et utilisé la commande ci-dessous, qui fonctionne. Sans exit, la commande restante se connectait réellement à la machine distante, ce que je ne voulais pas dans le script

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"
4
répondu Chintamani Manjare 2016-08-02 12:25:06

Généralement, ce problème se produit lorsque vous modifiez les clés très souvent. Basé sur le serveur, il peut prendre un certain temps pour mettre à jour la nouvelle clé que vous avez générée et collée dans le serveur. Donc, après avoir généré la clé et collé dans le serveur, attendez 3 à 4 heures, puis essayez. Le problème devrait être résolu. Il s'est passé avec moi.

2
répondu mk.. 2013-02-05 10:18:27

Faites ceci -> chmod + w ~/.ssh / known_hosts Cela ajoute l'autorisation d'écriture au fichier à ~/.ssh / known_hosts. Après que l'hôte distant sera ajouté au fichier known_hosts lorsque vous vous connectez pour la prochaine fois.

1
répondu Akshayraj Kore 2016-01-27 18:15:20

Idéalement, vous devriez créer une autorité de certification autogérée. Commencez par générer une paire de clés: ssh-keygen -f cert_signer

Signez ensuite la clé hôte publique de chaque serveur: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Cela génère une clé d'hôte publique signée: /etc/ssh/ssh_host_rsa_key-cert.pub

Dans /etc/ssh/sshd_config, pointez le HostCertificate vers ce fichier: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Redémarrez le service sshd: service sshd restart

Ensuite, sur le client SSH, ajoutez ce qui suit à ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Ce qui précède contient:

  • @cert-authority
  • le domaine *.example.com
  • Le contenu de la clé publique cert_signer.pub

La clé publique cert_signer fera confiance à tout serveur dont la clé hôte publique est signée par la clé privée cert_signer.

Bien que cela nécessite une configuration unique côté client, vous pouvez faire confiance à plusieurs serveurs, y compris ceux qui n'ont pas encore été provisionnés (à condition de signer chaque serveur).

Pour plus de détails, voir cette page du wiki.

1
répondu Robert Chen 2018-02-10 02:23:42

Je résous le problème qui donne ci-dessous l'erreur écrite:
Erreur:
L'authenticité de l'hôte 'XXX. XXX. XXX' ne peut être établie.
RSA Clé d'empreintes digitales est 09:6c:ef:cd:55:c4:4f:ss:5a: 88: 46: 0a:a9:27:83: 89.

Solution:
1. installez n'importe quel outil openSSH.
2. exécuter la commande ssh
3. il demandera de faire u ajouter cet hôte comme. accepter Oui.
4. Cet hôte ajoutera dans la liste des hôtes connus.
5. Maintenant, vous êtes en mesure de vous connecter avec cet hôte.

Cette solution fonctionne maintenant......

-3
répondu Rakesh Kumar Garg 2013-09-12 11:40:19