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


153

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?


27
Je déconseillerais cela. Vous devez comprendre pourquoi vous obtenez ces erreurs, sinon vous vous ouvrez à une attaque d'homme au milieu, ce contre quoi ces erreurs tentent de vous protéger.
Peter Bagnall

3
Cela peut être causé par un changement de serveur utilisant cette clé ssh ou par une personne assise entre vous et le serveur qui écoute tout ce que vous envoyez / recevez.
derekdreery

quelle pourrait être la raison de cette erreur?
AiU

Je ne suis pas d'accord avec l'argument de Peter. Dans une grande organisation, essayer de convaincre quelqu'un d'autre de résoudre des problèmes comme celui-là lorsque vous essayez simplement de faire votre travail est irréaliste.
Sridhar Sarnobat

De nombreuses grandes organisations sont exactement le contraire de ce que propose @SridharSarnobat. Vous devez vous assurer que les bonnes personnes résolvent ce genre de problèmes et tenter de les contourner ne fait qu'empirer les choses.
James Moore

Réponses:


135

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 .


40
Je pense qu'il est irresponsable de recommander cela sans avertir des implications de sécurité. superuser.com/a/421084/121091 est une meilleure réponse IMO.
Ian Dunn

5
@IanDunn Je serais d'accord avec vous dans une situation générale de client SSH, mais étant donné que l'OP indique clairement qu'il rencontre ce problème lors de l'exécution de scripts, l'alternative est de casser le script chaque fois que la clé hôte change (et il y a un certain nombre de raisons pour lesquelles cela pourrait être le cas) que la réponse dont vous avez parlé ne résout pas. Cela dit, c'est une critique valable, j'ai donc mis à jour ma réponse pour souligner le risque.
cori

6
Je ne peux pas croire que tant de gens aient voté pour cette réponse et aussi qu'elle soit acceptée par l'interlocuteur. Cette approche contourne les contrôles de sécurité et le connecte à l'hôte distant. Vérifiez si le fichier known_hosts dans le dossier ~ / .ssh / dispose d'une autorisation d'écriture. Sinon, utilisez cette réponse stackoverflow.com/a/35045005/2809294
ARK

Tant que vous savez ce que vous faites, c'est la meilleure solution. J'ai un site Web interne auquel nous nous connectons automatiquement et qui contient BEAUCOUP, mettant à jour (effectivement au hasard) les adresses IP. J'ai ajouté ceci à ~ / .ssh / config et cela fonctionne juste. Remarquez, JE SAIS que ce site est ce que je pense que c'est et si ce n'est pas le cas, les méchants n'ont aucun avantage, car je sais quelles données sont transférées.
user1683793 le

75

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)

4
Ou gérez simplement le fichier known_hosts pour toutes les machines dans le cadre de la configuration de votre infrastructure.
Thilo

1
notez que ssh-keyscan ne fonctionne pas avec ProxyCommand: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2
Richlv

1
cela ne fonctionnera pas comme prévu. `ssh-keygen -F $IP`devrait être "`ssh-keygen -F $IP`"(entre guillemets), dans les autres cas, il ne sera pas interprété comme une chaîne
avtomaton

Ou comme oneliner utilisant la valeur de retour ssh-kegen:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu

38

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


19

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


4
est-il sécurisé de permettre à tout le monde d'écrire sur les known_hosts?
akaRem

2
@akaRem certainement pas. Habituellement, vous souhaitez qu'il ne soit accessible en écriture que pour l'utilisateur propriétaire de ce .sshdossier.
2rs2ts

les permissions 0400sont optimales (veuillez me corriger n'importe qui) mais dans mon cas, le problème était simplement que le .sshdossier de mon utilisateur avait changé de propriété, ce qui invalide mes propres permissions 0400. sudole changement de propriétaire a résolu mon problème.
Charney Kaye

Celui-ci a résolu le problème pour moi.
Sivaji

14

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"

10

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.


Merci d'avoir vraiment sauvé la mise. Mais à quoi sert la dernière ligne IdentityFile? Cela semble fonctionner sans lui aussi ..
supersan

7

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

5

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"

5

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.


4

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 .


2

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.



0

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

chmod -R 700 ~/.ssh

demandez-vous aux gens de changer les autorisations sur les clés_autorisées et les clés publiques de 644 à 700? Et clé privée de 600 à 700?
nurettin le

0

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é.


-3

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 ......


Cela ne répond pas à la question. La question d'origine (très ancienne) portait sur la possibilité de confirmer automatiquement ces invites via un script.
MasterAM

Si cela a fonctionné pour lui, peut-être que cela fonctionne pour d'autres. Pas besoin de voter contre quelque chose qui est réellement utile
Mbotet

l'exécution de "ssh" ne fonctionne pas. Il affiche pour l'utilisation des options: ssh [..] [..] [..] [user @] hostname [commande]
P Satish Patro
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.