2012-05-05 23:39:28 +0000 2012-05-05 23:39:28 +0000
84
84

SSH : L'authenticité de l'hôte ne peut être établie

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

Ou est-ce simplement un message par défaut qui s'affiche toujours lors de la connexion à un nouveau serveur ?

J'ai l'habitude de voir ce message lorsque j'utilise SSH dans le passé : J'ai toujours entré mon login avec un mot de passe de la manière habituelle, et je me sentais bien car je n'utilisais pas de clés privées/publiques (ce qui est beaucoup plus sûr 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 la phrase de passe à la fin est une mesure de sécurité différente et supplémentaire, pour le décryptage de la clé privée.

J'espère que quelqu'un pourra donner une explication agréable de ce que signifie ce message “l'authenticité ne peut pas ê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':
Source

Réponses (7)

71
71
71
2012-05-06 00:23:59 +0000

Il vous dit que vous ne vous êtes jamais connecté à ce serveur auparavant. Si vous vous attendiez à cela, c'est tout à fait normal. Si vous êtes paranoïaque, vérifiez la somme de contrôle/empreinte digitale de la clé en utilisant un canal alternatif. (Mais notez que quelqu'un qui peut rediriger votre connexion ssh peut aussi rediriger une session de navigateur web).

Si vous vous êtes déjà connecté à ce serveur auparavant à partir de cette installation de ssh, alors soit le serveur a été reconfiguré avec une nouvelle clé, soit quelqu'un usurpe l'identité du serveur. En raison de la gravité d'une attaque de type “man-in-the-middle”, cela vous met en garde contre cette possibilité.

Dans tous les cas, vous disposez d'un canal crypté sécurisé vers quelqu'un. Personne sans la clé privée correspondant à l'empreinte digitale 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 ne peut décoder ce que vous envoyez.

La clé que vous utilisez pour vous authentifier n'a aucun rapport… vous ne voudriez pas envoyer des informations d'authentification à un serveur frauduleux qui pourrait les voler, et vous ne devriez donc pas vous attendre à des changements selon que vous allez utiliser une phrase de passe ou une clé privée pour vous connecter. Vous n'êtes tout simplement pas encore arrivé à ce stade du processus.
Source
23
23
23
2016-08-10 11:42:38 +0000

Disons que vous rencontrez quelqu'un pour échanger quelques secrets d'affaires. Votre conseiller vous dit que vous n'avez jamais rencontré cette personne auparavant et qu'il peut s'agir d'un imposteur. De plus, pour les prochaines rencontres avec lui, votre conseiller ne vous avertira plus. C'est ce que signifie le message. 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 pourriez ouvrir une page web avec une photo d'elle et la comparer avec le visage devant vous. Pour le serveur Bitbucket, vous pourriez utiliser un autre ordinateur, plus fiable, et en extraire la photo de son visage, puis la comparer avec celle que vous obtenez dans l'ordinateur que vous utilisez actuellement. Utilisez : 

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 avertira 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 “man-in-the-middle”), le client ssh rejettera la connexion parce que le visage aura changé.
Source
5
5
5
2014-07-16 15:44:43 +0000

J'ai simplement dû créer le fichier texte known_hosts dans ~/.ssh 

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

Après avoir fait cela, il a ajouté l'hôte et je n'ai jamais revu le message.
Source
2
2
2
2014-12-16 08:23:53 +0000

Il existe une autre solution 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é rsa sera ajoutée aux hôtes connus et ne demandera pas de “oui” pour la confirmation de l'authenticité
Source
1
1
1
2012-05-05 23:52:02 +0000

Ce message est juste un message SSH vous disant qu'il n'a jamais vu cette clé d'hôte particulière avant, donc il n'est pas capable de vérifier vraiment que vous vous connectez à l'hôte que vous pensez être. Lorsque vous dites “Oui”, il place la clé ssh dans votre fichier d'hôtes connus, puis lors des connexions suivantes, il compare la clé qu'il obtient de l'hôte à celle du fichier d'hôtes connus.

Un article connexe sur le débordement de la pile montre comment désactiver cet avertissement, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .
Source
0
0
0
2017-11-04 13:51:11 +0000

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é à partir de l'hôte actuel (à cet hôte) ; ce n'est que psychologiquement différent ; vous pensez vous connecter à partir de l'hôte A (vers B), alors qu'en réalité vous essayez de vous connecter à partir de l'hôte X (vers B). Cela peut par exemple se produire lorsque vous vous connectez d'abord de A à X et que vous essayez ensuite de vous connecter de A à B depuis le même terminal en pensant que vous êtes toujours sur A.
Source
0
0
0
2018-05-11 11:03:59 +0000

Dans mon cas, la connexion sans mot de passe ne fonctionnait pas en raison des autorisations de mon répertoire personnel, car j'ai 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/nom d'utilisateur/.ssh 

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

/home/nom d'utilisateur/.ssh/authorized_keys 

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