Quand je ssh sur une machine, je reçois parfois 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 '' 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.
Y a-t-il un moyen de dire automatiquement “oui” ou d’ignorer cela?
Selon votre client ssh, vous pouvez définir l’option SsortingctHostKeyChecking sur no sur la ligne de commande et / ou envoyer la clé à un fichier null known_hosts. 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ôte.
ssh -o UserKnownHostsFile=/dev/null -o SsortingctHostKeyChecking=no
MODIFIER
Comme le fait remarquer @IanDunn, cela comporte des risques pour la sécurité. Si un attaquant usurpait la ressource à laquelle vous vous connectiez, il pourrait éventuellement relire le défi du serveur de destination, vous faisant croire que vous vous connectez à la ressource distante alors qu’en fait, elle se connecte à cette ressource avec: vos informations d’identification. Vous devez examiner attentivement si cela représente un risque approprié 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 SsortingctHostKeyChecking
(qui n’est pas sécurisé).
Incorporer 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 se trouve dans known_hosts
. Sinon, il demande une clé publique au serveur et l’ajoute à known_hosts
.
De cette façon, vous êtes exposé à l’attaque de Man-In-The-Middle une seule fois, ce qui peut être atténué par:
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.* SsortingctHostKeyChecking=no UserKnownHostsFile=/dev/null
Options:
*
pour autoriser un access illimité à toutes les adresses IP. /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 https://superuser.com/a/628801/55163
Assurez-vous que ~/.ssh/known_hosts
est accessible en écriture. Cela a réglé pour moi.
Editez 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 SsortingctHostKeyChecking no IdentityFile ~/my_path/id_rsa.pub
L’utilisateur défini sur your_login_user
indique que ce paramètre appartient à your_login_user
SsortingctHostKeyChecking défini sur no évite l’invite
IdentityFile est le chemin d’access à la clé RSA
Cela fonctionne pour moi et mes scripts, bonne chance à vous.
Le meilleur moyen d’y parvenir est d’utiliser ‘BatchMode’ en plus de ‘SsortingctHostKeyChecking’. 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 par oui / non.
ssh -o BatchMode=yes -o SsortingctHostKeyChecking=no [email protected] "uptime"
Cet avertissement est émis en raison des fonctionnalités de sécurité, ne désactivez pas cette fonctionnalité.
C’est juste affiché une fois.
S’il apparaît toujours après la deuxième connexion, le problème vient probablement de l’écriture dans le fichier known_hosts
. Dans ce cas, vous recevrez également le message suivant:
Failed to add the host to the list of known hosts
Vous pouvez résoudre le problème en changeant le propriétaire de modifier les permissions du fichier pour qu’il soit accessible en écriture par votre utilisateur.
sudo chown -v $USER ~/.ssh/known_hosts
En ce qui concerne la réponse de Cori, je l’ai modifiée et utilisée ci-dessous la commande, qui fonctionne. Sans exit
, la commande restante était en train de se connecter à une machine distante, ce que je ne voulais pas en script
ssh -o SsortingctHostKeyChecking=no user@ip_of_remote_machine "exit"
Généralement, ce problème se produit lorsque vous modifiez les clés très souvent. Selon le 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 devrait être résolu. C’est arrivé avec moi.
Faites ceci -> chmod + w ~ / .ssh / known_hosts Cela ajoute des permissions d’écriture sur le fichier à ~ / .ssh / known_hosts. Après cela, l’hôte distant sera ajouté au fichier known_hosts lorsque vous vous y connecterez la prochaine fois.
Idéalement, vous devez créer une autorité de certificateion 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 le fichier HostCertificate
sur 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
*.example.com
cert_signer.pub
La cert_signer
publique cert_signer
approuve tout serveur dont la clé d’hôte publique est signée par la cert_signer
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 que vous signez chaque serveur).
Pour plus de détails, voir cette page wiki .
Je résous le problème qui donne ci-dessous une erreur écrite:
Erreur:
L’authenticité de l’hôte ‘XXX.XXX.XXX’ ne peut pas être établie.
L’empreinte de clé RSA est 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.
Solution:
1. installez tout outil openSSH.
2. exécuter la commande ssh
3. il vous demandera si vous ajoutez cet hôte comme. accepter OUI.
4. Cet hôte appenda dans la liste des hôtes connus.
5. Vous pouvez maintenant vous connecter avec cet hôte.
Cette solution fonctionne maintenant ……