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

Quand je ssh sur une machine, parfois j'obtiens cet avertissement d'erreur et il me demande de dire "oui" ou "non". Cela pose des problèmes lors de l'exécution de scripts qui ssh automatiquement vers d'autres machines.

Message d'alerte:

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 de l'ignorer?

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é vers un fichier known_hosts nul. 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

ÉDITER

Comme le note @IanDunn, il y a des risques de sécurité à faire cela. Si la ressource à laquelle vous vous connectez a été usurpée par un attaquant, il pourrait potentiellement vous rejouer le défi du serveur de destination, 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 devez examiner attentivement si c'est un risque approprié à prendre avant de modifier votre mécanisme de connexion pour ignorer HostKeyChecking.

Référence .

Ancienne 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écurisé).

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

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

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

Pour désactiver (ou contrôler 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 *permettre un accès illimité à toutes les adresses IP.
• Modifier /etc/ssh/ssh_configpour la configuration globale ou ~/.ssh/configpour 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 https://superuser.com/a/628801/55163

Assurez-vous qu'il ~/.ssh/known_hostsest accessible en écriture. Cela a résolu le problème pour moi.

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"

Modifiez votre fichier de configuration normalement situé dans '~ / .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_userindique que ce paramètre appartient à your_login_user
StrictHostKeyChecking défini sur no évitera l'invite
IdentityFile est le chemin vers la clé RSA

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

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

Il n'est affiché qu'une seule fois.

S'il apparaît toujours après la deuxième connexion, le problème est probablement lié à l'écriture dans le known_hostsfichier. Dans ce cas, vous recevrez également le message suivant:

Failed to add the host to the list of known hosts 

Vous pouvez le résoudre en changeant le propriétaire ou en modifiant les autorisations du fichier pour qu'il soit accessible en écriture par votre utilisateur.

sudo chown -v $USER ~/.ssh/known_hosts

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

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

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

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

Ensuite, signez la clé d'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 HostCertificatesur 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 complet de la clé publique cert_signer.pub

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

Bien que cela nécessite une configuration unique côté client, vous pouvez approuver plusieurs serveurs, y compris ceux qui n'ont pas encore été provisionnés (tant que vous signez chaque serveur, c'est-à-dire).

Pour plus de détails, consultez cette page wiki .

Généralement, ce problème se produit lorsque vous modifiez les clés très souvent. En fonction du serveur, la mise à jour de la nouvelle clé que vous avez générée et collée sur le serveur peut prendre un certain temps. Donc, après avoir généré la clé et collé dans le serveur, attendez 3 à 4 heures, puis essayez. Le problème doit être résolu. C'est arrivé avec moi.

Ajoutez-les à votre / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Exécutez ceci dans le serveur hôte, c'est un problème de prémonition

chmod -R 700 ~/.ssh

J'ai eu la même erreur et je voulais attirer l'attention sur le fait que - comme cela m'est arrivé - vous pourriez avoir simplement de mauvais privilèges.
Vous avez configuré votre .sshrépertoire en tant que standard ou rootutilisateur et vous devez donc être le bon utilisateur. Lorsque cette erreur est apparue, j'étais, rootmais j'ai configuré en .sshtant qu'utilisateur régulier. Quitter l'a rootcorrigé.

Je résous le problème qui donne l'erreur écrite ci-dessous:
Erreur:
L'authenticité de l'hôte 'XXX.XXX.XXX' ne peut pas être établie.
L'empreinte digitale de la clé RSA 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écutez la commande ssh
3. il vous demandera d'ajouter cet hôte comme. accepter OUI.
4. Cet hôte s'ajoutera à la liste d'hôtes connus.
5. Vous pouvez maintenant vous connecter à cet hôte.

Cette solution fonctionne maintenant ......