webentwicklung-frage-antwort-db.com.de

SSH: Die Authentizität von Host <Host> kann nicht festgestellt werden

Was bedeutet diese Nachricht? Ist das ein potentielles Problem? Ist der Kanal nicht sicher?

Oder ist dies einfach eine Standardnachricht, die immer angezeigt wird, wenn eine Verbindung zu einem neuen Server hergestellt wird?

Ich bin es gewohnt, diese Meldung bei der Verwendung von SSH in der Vergangenheit zu sehen: Ich habe meinen Anmeldenamen immer wie gewohnt mit einem Passwort eingegeben, und ich fühlte mich gut dabei, weil ich keine privaten/öffentlichen Schlüssel verwendete (was viel sicherer ist) als ein kurzes Passwort). Aber diesmal habe ich mit ssh einen öffentlichen Schlüssel für meine Verbindung zu bitbucket eingerichtet, aber ich habe immer noch die Nachricht erhalten. Mir ist bekannt, dass die Passwortabfrage am Ende eine andere, zusätzliche Sicherheitsmaßnahme für die Entschlüsselung des privaten Schlüssels darstellt.

Ich hoffe, jemand kann eine nette Erklärung für das geben, was mit dieser Nachricht "Authentizität kann nicht hergestellt werden" gemeint ist.

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':
76
Steven Lu

Es sagt Ihnen, dass Sie noch nie eine Verbindung zu diesem Server hergestellt haben. Wenn Sie das erwartet haben, ist es völlig normal. Wenn Sie paranoid sind, überprüfen Sie die Prüfsumme/den Fingerabdruck des Schlüssels mithilfe eines alternativen Kanals. (Beachten Sie jedoch, dass jemand, der Ihre SSH-Verbindung umleiten kann, auch eine Webbrowsersitzung umleiten kann.)

Wenn Sie vor der Installation von ssh eine Verbindung zu diesem Server hergestellt haben, wurde der Server entweder mit einem neuen Schlüssel neu konfiguriert oder die Identität des Servers wurde gefälscht. Aufgrund der Schwere eines Man-in-the-Middle-Angriffs warnt es Sie vor der Möglichkeit.

In jedem Fall haben Sie einen sicheren verschlüsselten Kanal zu jemandem . Niemand ohne den privaten Schlüssel, der dem Fingerabdruck 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 entspricht, kann entschlüsseln, was Sie senden.

Der Schlüssel, mit dem Sie sich authentifizieren, hat nichts mit Ihnen zu tun. Sie möchten keine Authentifizierungsinformationen an einen betrügerischen Server senden, der sie möglicherweise stiehlt. Sie sollten daher keine Änderungen erwarten, je nachdem, ob Sie eine Passphrase oder eine verwenden Privater Schlüssel zum Einloggen. Sie sind dabei einfach noch nicht so weit gekommen.

67
Ben Voigt

Nehmen wir an, Sie treffen jemanden, um ein paar Geschäftsgeheimnisse auszutauschen. Ihr Berater teilt Ihnen mit, dass Sie diese Person noch nie zuvor getroffen haben und dass dies ein Betrüger sein kann. Außerdem wird Ihr Berater Sie für die nächsten Treffen mit ihm nicht mehr warnen. Das ist es, was die Botschaft bedeutet. Die Person ist der Remote-Server, und Ihr Berater ist der SSH-Client.

Ich halte es nicht für paranoid, die Identität der Person zu überprüfen, bevor man ihr Geheimnisse mitteilt. Zum Beispiel könnten Sie eine Webseite mit einem Bild von ihr öffnen und es mit dem Gesicht vor Ihnen vergleichen. Oder überprüfen Sie ihren Personalausweis.

Für den Bitbucket-Server könnten Sie einen anderen, vertrauenswürdigeren Computer verwenden und das Bild seines Gesichts von ihm abrufen und es dann mit dem vergleichen, das Sie auf dem Computer erhalten, den Sie gerade verwenden. Benutzen:

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

Wenn das Gesichter übereinstimmt, können Sie den Schlüssel zur Datei hinzufügen, z. ~/.ssh/known_hosts (Standardverzeichnis in vielen Linux-Distributionen) mit:

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

und der ssh client wird dich nicht warnen, da er ihr gesicht bereits kennt. Es vergleicht die Gesichter jedes Mal, wenn Sie eine Verbindung herstellen. Das ist sehr wichtig. Im Falle eines Betrügers (z. B. eines Man-in-the-Middle-Angriffs) lehnt der ssh-Client die Verbindung ab, da sich face geändert hat.

19
Ivan Ogai

Ich musste einfach die known_hosts-Textdatei in ~/.ssh erstellen

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

Danach fügte es den Host hinzu und ich sah die Nachricht nie wieder.

5
Brian

Es gibt eine andere einfache Möglichkeit. Berühre einfach eine "config" -Datei unter /root/.ssh und füge den Parameter StrictHostKeyChecking hinzu. zur Echtheitsbestätigung

1
Usman

Bei dieser Nachricht handelt es sich lediglich um eine SSH-Nachricht, die Ihnen mitteilt, dass dieser bestimmte Hostschlüssel noch nie zuvor gesehen wurde. Sie kann also nicht wirklich überprüfen, ob Sie eine Verbindung zu dem Host herstellen, den Sie für richtig halten. Wenn Sie "Ja" sagen, wird der SSH-Schlüssel in die Datei "known_hosts" eingefügt. Bei nachfolgenden Verbindungen wird der vom Host erhaltene Schlüssel mit dem in der Datei "known_hosts" verglichen.

In einem verwandten Artikel zum Stapelüberlauf wurde gezeigt, wie diese Warnung deaktiviert werden kann. https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-Host-hostname-cant-be-established .

1
Mike

Abgesehen von den bereits gegebenen Antworten (Sie haben noch nie eine Verbindung zu diesem Host hergestellt), besteht auch die eindeutige Möglichkeit, dass Sie noch nie eine Verbindung zum aktuellen Host (zu diesem Host) hergestellt haben. das ist nur psychologisch anders; Sie denken, dass Sie eine Verbindung von Host A (zu B) herstellen, während Sie wirklich versuchen, eine Verbindung von Host X (zu B) herzustellen. Dies kann zum Beispiel passieren, wenn Sie zuerst von A nach X und dann vom selben Terminal aus versuchen, nach B zu ssh, weil Sie glauben, dass Sie immer noch auf A sind.

0
Carlo Wood

In meinem Fall funktionierte die Anmeldung ohne Kennwort aufgrund meiner Berechtigungen für das Basisverzeichnis nicht, da ich die Standardeinstellungen geändert habe. Schließlich ist hier, was für mich gearbeitet hat. Meine Home-Verzeichnis-Berechtigungen sind

/ home/benutzername

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
0