ssh: L'authenticité du « nom d'hôte » hôte ne peut pas être établie

Question

Quand je ssh à une machine, quelque temps que je reçois cet avertissement d'erreur et il invite à dire « oui » ou « non ». Cette cause quelques problèmes lors de l'exécution de scripts ssh automatiquement à 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.

Est-il possible de dire automatiquement « oui » ou ignorer cela?

Answer 1

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

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

EDIT

Notes Comme @IanDunn, il y a des risques de sécurité pour le faire. Si la ressource que vous vous connectez à a été usurpée par un attaquant, ils pourraient rejouer le dos pour vous défi de serveur de destination, vous duper en pensant que vous vous connectez à la ressource à distance alors qu'en fait, ils se connectent à cette ressource avec vos informations d'identification. Vous devriez examiner attentivement si c'est un risque approprié de prendre avant de modifier votre mécanisme de connexion pour sauter HostKeyChecking.

Référence .

Answer 2

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

Vous pouvez empêcher invite interactive sans désactiver StrictHostKeyChecking (qui est non 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 en known_hosts. Dans le cas contraire, il demande la clé publique du serveur et ajoute à known_hosts.

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

• veiller à ce que le script se connecte 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)

Answer 3

Pour désactiver (ou la désactivation de commande), 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

Une question similaire sur superuser.com - voir https://superuser.com/a/628801/55163

Answer 4

Assurez-vous que ~/.ssh/known_hosts est inscriptible. Qui a été fixé pour moi.

Answer 5

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

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

Answer 6

Modifier votre fichier de configuration normalement situé à ~ / .ssh / config ', et au beggining du fichier, ajoutez le dessous des lignes

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

Paramétrables à your_login_user dit que ce paramètre appartient à your_login_user
StrictHostKeyChecking ensemble à n'évitera l'invite
IdentityFile est le chemin à la clé RSA

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

Answer 7

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

Il est juste affiché une fois.

Si elle apparaît toujours après la deuxième connexion, le problème est probablement par écrit au fichier known_hosts. Dans ce cas, vous aurez également le message suivant:

Failed to add the host to the list of known hosts 

Vous pouvez le fixer en changeant le propriétaire de modifier les permissions du fichier pour être accessible en écriture par votre utilisateur.

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

Answer 8

En ce qui concerne la réponse de Cori, je l'ai modifié et utilisé ci-dessous commande, qui travaille. Sans exit, commande restante enregistrait en fait à la machine à distance, que je ne voulais pas dans le script

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

Answer 9

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

Answer 10

En général ce problème se produit lorsque vous modifiez les clés très oftenly. Basé sur le serveur, il peut prendre un certain temps pour mettre à jour la nouvelle clé que vous avez généré et collé dans le serveur. Ainsi, après avoir généré la clé et le coller dans le serveur, attendez 3 à 4 heures, puis essayer. Le problème devrait être résolu. Il est arrivé avec moi.

Answer 11

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

signe ensuite 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

En /etc/ssh/sshd_config, point le HostCertificate à 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/

ci-dessus contient:

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

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

Bien que cela nécessite une configuration unique du côté client, vous pouvez faire confiance à plusieurs serveurs, y compris ceux qui ne sont pas encore provisionné (aussi longtemps que vous signez chaque serveur, qui est).

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

Answer 12

Ajoutez-les à votre / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Answer 13

Exécuter ce dans le serveur hôte, il question de prémonition

chmod -R 700 ~/.ssh

Answer 14

J'ai eu la même erreur et je voulais attirer l'attention sur le fait que - comme il vient de se passer pour moi -. Vous pourriez avoir de mauvaises privilèges
Vous avez configuré votre répertoire .ssh que soit utilisateur régulier ou root et donc vous devez être l'utilisateur correct. Lorsque cette erreur est apparue, j'étais root mais je .ssh configuré comme utilisateur régulier. root fixé il sortie.

Answer 15

Je résous la question qui donne ci-dessous une erreur écrite:
Erreur:
L'authenticité de l'hôte « XXX.XXX.XXX » ne peut être établie.
empreinte de clé RSA est 09: 6c: ef: cd: 55: c4: 4F: ss: 5a: 88: 46: 0a: a9: 27: 83:. 89

Solution:
1. installer un outil OpenSSH.
2. Exécuter la commande ssh
3. il demandera do u ajouter cet hôte comme.    accepter OUI.
4. Cet hôte ajoutera dans la liste d'hôtes connue.
5. Maintenant, vous êtes en mesure de se connecter à cet hôte.

Cette solution fonctionne maintenant ......