SSH: L'authenticité de l'hôte <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 est 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 (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':
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 avez déjà connecté ce serveur à partir de 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 de type homme au milieu, il vous avertit de la possibilité.
De toute façon, vous avez 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 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 modifications selon que vous utilisiez une phrase secrète ou non. clé privée pour vous connecter. Vous n'avez tout simplement pas encore atteint ce stade du processus.
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, et obtenir la image de son visage à partir de celui-ci, 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 sait déjà son visage . Il comparera les visages chaque fois que vous vous connectez. 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 face aura changé.
Je devais simplement créer le fichier texte known_hosts 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 jamais revu le message.
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é sera rsa ajoutée à known_hosts et ne demandera pas "yes". pour confirmation de l'authenticité
Ce message est simplement SSH qui vous dit que cette clé d’hôte 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.
Il y avait un article connexe sur le dépassement de pile indiquant comment désactiver cet avertissement, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-Host-hostname-cant-be-established .
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 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.
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