SSH: l'authenticité de l'hôte <hôte> ne peut pas être établie

83

Que signifie ce message? Est-ce un problème potentiel? Le canal n'est-il pas sécurisé?

Ou s'agit-il simplement d'un message par défaut toujours affiché lors de la connexion à un nouveau serveur?

J'avais l'habitude de voir ce message lorsque j'utilisais SSH dans le passé: j'ai toujours entré mon identifiant avec un mot de passe comme d'habitude, et je me sentais bien parce que je n'utilisais pas de clés privées / publiques (ce qui est beaucoup plus sécurisé qu'un mot de passe court). Mais cette fois, j'ai configuré une clé publique avec ssh pour ma connexion à bitbucket mais j'ai quand même reçu le message. Je suis conscient que l'invite de phrase secrète à la fin est une mesure de sécurité supplémentaire, différente, pour le déchiffrement de la clé privée.

J'espère que quelqu'un pourra donner une bonne explication de ce que signifie ce message "l'authenticité ne peut être établie".

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':

ssh security encryption

— Steven Lu
source

2

C’est vraiment un de ces messages qui "signifie exactement ce qu’il dit". Cela signifie qu’il sshn’ya aucun moyen de dire à qui vous parlez vraiment bitbucket.org. Si vous avez configuré un moyen de le savoir, cela ne fonctionne pas. Si vous ne l'avez pas fait, cela vous dit que vous ne l'avez pas fait.

— David Schwartz

71

Cela vous dit que vous ne vous êtes jamais connecté à ce serveur auparavant. Si vous vous attendiez à cela, c'est parfaitement normal. Si vous êtes paranoïaque, vérifiez la somme de contrôle / l'empreinte digitale de la clé en utilisant un autre canal. (Notez cependant que quelqu'un qui peut rediriger votre connexion ssh peut également rediriger une session de navigateur Web.)

Si vous vous êtes déjà connecté à ce serveur depuis cette installation de ssh, le serveur a été reconfiguré avec une nouvelle clé ou quelqu'un usurpe l'identité du serveur. En raison de la gravité d'une attaque interceptée, il vous avertit de la possibilité.

De toute façon, vous avez un canal crypté sécurisé à quelqu'un . Personne sans la clé privée correspondant à une empreinte digitale 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40ne peut décoder ce que vous envoyez.

La clé que vous utilisez pour vous authentifier n’a pas de lien ... vous ne voudriez pas envoyer d’informations d’authentification à un serveur frauduleux qui pourrait les voler, et vous ne devriez donc pas vous attendre à des changements selon que vous utilisiez une phrase secrète ou non. clé privée pour vous connecter. Vous n'avez tout simplement pas encore progressé dans le processus.

— Ben Voigt
source

Donc, même s'il existe une tierce partie malveillante et que je rejette le message, tout ce que je vais faire, c'est lui envoyer ma clé publique et il ne pourra toujours pas déchiffrer mes données? Ainsi, à présent, mes données ne peuvent être compromises que si (1) ma clé privée est compromise, (2) les serveurs de bitbucket sont compromis ou (3) mon compte bitbucket est compromis. Tant qu'ils limitent les tentatives de connexion (ce qui m'étonnerait vraiment s'ils ne le font pas), il n'y a pas beaucoup de raisons d'être paranoïaque à ce stade, hein?

— Steven Lu

10

@ Steven: Vous ne lui envoyez pas votre clé publique, il l'a déjà. Ce que vous faites, c'est utiliser votre clé privée pour authentifier un défi ... s'il se connectait au vrai bitbucket.org prétendant être vous, recevait le véritable défi, et utilisait ce défi pour vous lancer un défi, il pourrait alors vous tromper en lui envoyant une réponse valide qu'il utilise ensuite pour accéder à votre compte sur le vrai bitbucket.org. Il n'a toujours pas votre clé privée. Il ne peut donc plus se connecter, ni à aucune autre ressource déverrouillée par une clé, mais il ne dispose que d'une session.

— Ben Voigt

C'est ce que je voulais dire dans ma réponse lorsque j'ai dit "vous ne voudriez pas envoyer d'informations d'authentification à un serveur frauduleux".

— Ben Voigt

2

"Si vous êtes paranoïaque, vérifiez la somme de contrôle / l'empreinte digitale de la clé en utilisant un autre canal." Pour les paranoïaques (et pour mémoire), les empreintes digitales de github sont sur help.github.com/articles/generating-ssh-keys et celles de bitbucket sont mentionnées dans confluence.atlassian.com/display/BITBUCKET/…

— sundar

1

@ BenVoigt Ouais, je comprends que le véritable paranoïaque accède à ces pages via un réseau différent, ou peut-être aller au siège de github et obtenir son empreinte digitale en personne :)

— mardi,

21

Disons que vous rencontrez quelqu'un pour échanger des secrets d'affaires. Votre conseiller vous dit que vous n'avez jamais rencontré cette personne auparavant et que cela peut être un imposteur. De plus, lors des prochaines réunions avec lui, votre conseiller ne vous préviendra plus. C'est ce que le message signifie. La personne est le serveur distant et votre conseiller est le client ssh.

Je ne pense pas qu'il soit paranoïaque de vérifier l'identité de la personne avant de partager des secrets avec elle. Par exemple, vous pouvez ouvrir une page Web avec une photo d'elle et la comparer au visage qui se trouve devant vous. Ou vérifiez sa carte d'identité.

Pour le serveur bitbucket, vous pouvez utiliser un ordinateur différent, plus fiable, obtenir l' image de son visage , puis le comparer à celui que vous obtenez sur l'ordinateur que vous utilisez maintenant. Utilisation:

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Si les faces correspondent, vous pouvez ajouter la clé au fichier, par exemple ~/.ssh/known_hosts(emplacement standard dans de nombreuses distributions Linux) avec:

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

et le client ssh ne vous préviendra pas car il connaît déjà son visage . Il comparera les visages à chaque fois que vous vous connecterez. C'est très important. Dans le cas d'un imposteur (par exemple, une attaque de type homme au milieu), le client ssh rejettera la connexion car le visage aura changé.

— Ivan Ogai
source

Cette réponse est très utile

— 010110110101

4

Cela devrait être la réponse acceptée: ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts Merci Ivan!

— Rod

1

@Rod: Vous choisiriez la réponse acceptée en fonction d'une commande totalement inutile (vous pouvez le modifier known_hostsen tapant simplement "oui" dans l'avertissement d'origine, comme indiqué dans la question) et dangereuse (la clé que vous avez ajoutée à votre message). Le fichier n’est pas nécessairement celui que vous avez regardé, car vous l’avez récupéré deux fois!)?

— Ben Voigt

@BenVoigt ce que cette solution fournit en tapant "oui", c'est que cette solution est entièrement scriptable. Je suppose que la plupart des gens peuvent comprendre comment réagir au "(oui / non)?" rapide. Je suis tombé sur ce Q & A en essayant de trouver un moyen de résoudre ce problème sans intervention humaine (pour un script de configuration de serveur). Dans mon excitation, je suppose que je n'ai pas remarqué que la question du PO est un peu différente de la mienne, mais OMI, c'est toujours la réponse la plus utile / non évidente du fil.

— Rod

1

@Rod: Non, ce n'est pas utile. Abaisser votre sécurité est mauvais. Trouver des moyens plus rapides d'abaisser votre sécurité est l'exact opposé de l'utile.

— Ben Voigt le

5

Je devais simplement créer le known_hostsfichier texte dans~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

Après cela, il a ajouté l'hôte et je n'ai plus jamais revu le message.

— Brian
source

Je ne pense pas que cela change vraiment quelque chose. L'avertissement est affiché lorsque le serveur lui-même a changé. Par exemple, si vous configurez une nouvelle machine virtuelle à laquelle vous vous connectez pour la première fois. Que vous ayez ou non un known_hostsfichier (avec les autorisations appropriées) ne l’empêche pas de vous interroger sur l’authenticité du nouveau serveur ... sauf si vous avez déjà récupéré la signature de la clé de publication de ce serveur et l’avez placée dans votre known_hosts, qui est la seule façon normale de passer le chèque (bien que simplement dire "oui" au chèque est souvent plus rapide pour obtenir le même résultat)

— Steven Lu

Merci. Je connaissais des hôtes, mais je continuais à recevoir l'avertissement. Il me suffisait de modifier les autorisations sur known_hosts pour que les avertissements cessent.

— ArcaneDominion

6

S'il vous plaît ne faites pas ça. Peut être un grave danger pour la sécurité. Votre fichier hôte ne devrait être accessible en écriture pour vous. La deuxième commande permet essentiellement à n'importe qui sur votre ordinateur d'usurper les identités de serveur.

— Stolz

"L'avertissement est affiché lorsque le serveur lui-même a changé." Ou lorsque le serveur n'a jamais été visité auparavant.

— Rod

2

Il existe un autre moyen simple: il suffit de toucher un fichier "config" sous /root/.ssh et d'ajouter le paramètre StrictHostKeyChecking no. La prochaine fois que vous vous connecterez à un serveur, la clé correspondante sera ajoutée à la commande unknown_hosts et ne demandera pas "oui". pour confirmation de l'authenticité

— Usman
source

3

Ceci n'est pas recommandé. C'est facile mais ce n'est pas la bonne façon de gérer la situation.

— Vikas

1

Ce message est simplement SSH qui vous dit que cette clé d’hôte particulière n’a jamais été vue auparavant. Il ne peut donc pas vraiment vérifier que vous vous connectez à l’hôte que vous pensez être. Lorsque vous dites "Oui", la clé ssh est insérée dans votre fichier known_hosts. Les connexions suivantes comparent ensuite la clé obtenue de l'hôte à celle du fichier known_hosts.

Un article connexe sur le dépassement de pile montre comment désactiver cet avertissement, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .

— Mike
source

10

Mais désactiver l’avertissement n’est pas recommandé - il est là pour quelque chose, fournissant des informations de sécurité très utiles.

— Rory Alsop

0

Outre les réponses déjà données (vous ne vous êtes jamais connecté à cet hôte auparavant), il est également possible que vous ne vous soyez jamais connecté depuis l'hôte actuel auparavant (à cet hôte); ce n'est que psychologiquement différent; vous pensez que vous vous connectez à partir de l'hôte A (à B), alors que vous essayez réellement de vous connecter à partir de l'hôte X (à B). Cela peut par exemple se produire lorsque vous commencez par ssh-ed de A à X puis, depuis le même terminal, essayez de ssh à B en pensant que vous êtes toujours sur A.

— Carlo Wood
source

Je me demande si l'utilisation du transfert d'agent ssh peut également supprimer l'avertissement si l'hôte A connaît B, mais X ne le sait pas, mais que le transfert d'agent a lieu entre A et X. La plupart des environnements (qui fournissent ssh) et des applications de terminal réduisez le nombre de clés SSH que vous devez gérer uniquement pour vos périphériques finaux.

— Steven Lu

0

Dans mon cas, la connexion sans mot de passe ne fonctionnait pas à cause des autorisations de mon répertoire personnel, car j'avais modifié les paramètres par défaut. Enfin, voici ce qui a fonctionné pour moi. les autorisations de mon répertoire personnel sont

/ home / nom d'utilisateur

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys

— Mian Asbat Ahmad
source