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

SSH: Die Authentizität des Hosts kann nicht festgestellt werden

Was bedeutet diese Meldung? Ist dies ein potenzielles Problem? Ist der Kanal nicht sicher?

Oder ist dies einfach eine Standardmeldung, die immer angezeigt wird, wenn man sich mit einem neuen Server verbindet?

Ich bin es gewohnt, diese Meldung zu sehen, wenn ich in der Vergangenheit SSH verwendet habe: Ich habe meine Anmeldung immer auf dem normalen Weg mit einem Passwort eingegeben, und ich fühlte mich gut dabei, weil ich keine privaten/öffentlichen Schlüssel benutzte (was viel sicherer ist als ein kurzes Passwort). Aber dieses Mal habe ich einen öffentlichen Schlüssel mit ssh für meine Verbindung zu bitbucket eingerichtet, aber ich habe die Nachricht trotzdem erhalten. Ich bin mir bewusst, dass die Passphrase-Eingabeaufforderung am Ende eine andere, zusätzliche Sicherheitsmaßnahme für die Entschlüsselung des privaten Schlüssels ist.

Ich hoffe, dass jemand eine nette Erklärung dafür geben kann, was mit dieser Nachricht “Authentizität kann nicht festgestellt 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':
Quelle

Antworten (7)

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

Es sagt Ihnen, dass Sie sich noch nie mit diesem Server verbunden haben. Wenn Sie das erwartet haben, ist das völlig normal. Wenn Sie paranoid sind, überprüfen Sie die Prüfsumme/Fingerabdruck des Schlüssels über einen alternativen Kanal. (Aber beachten Sie, dass jemand, der Ihre ssh-Verbindung umleiten kann, auch eine Webbrowser-Sitzung umleiten kann)

Wenn Sie sich von dieser ssh-Installation aus schon einmal mit diesem Server verbunden haben, dann wurde entweder der Server mit einem neuen Schlüssel neu konfiguriert, oder jemand täuscht die Identität des Servers vor. Aufgrund der Schwere eines Man-in-the-Middle-Angriffs warnt er Sie vor dieser Möglichkeit.

So oder so, Sie haben einen sicheren verschlüsselten Kanal zu jemand. 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, den Sie zur Authentifizierung verwenden, hat nichts damit zu tun… Sie würden keine Authentifizierungsinformationen an einen betrügerischen Server senden wollen, der sie stehlen könnte, und deshalb sollten Sie keine Änderungen erwarten, je nachdem, ob Sie eine Passphrase oder einen privaten Schlüssel zur Anmeldung verwenden werden. So weit sind Sie in diesem Prozess einfach noch nicht gekommen.
Quelle
23
23
23
2016-08-10 11:42:38 +0000

Sagen wir, Sie treffen sich mit jemandem, um einige Geschäftsgeheimnisse auszutauschen. Ihr Berater sagt Ihnen, dass Sie diese Person noch nie zuvor getroffen haben und dass es sich um einen Hochstapler handeln kann. Außerdem wird Ihr Berater Sie bei den nächsten Treffen mit ihm nicht mehr warnen. Das ist es, was die Botschaft bedeutet. Die Person ist der Fernserver, und Ihr Berater ist der ssh-Client.

Ich glaube nicht, dass es paranoid ist, die Identität der Person doppelt zu überprüfen, bevor man Geheimnisse mit ihr teilt. Sie könnten zum Beispiel eine Webseite mit einem Bild von ihr öffnen und es mit dem Gesicht vor Ihnen vergleichen. Oder ihren Personalausweis überprüfen.

Für den Bitbucket-Server könnten Sie einen anderen, vertrauenswürdigeren Computer verwenden und das Bild seines Gesichtes von ihm holen und es dann mit dem vergleichen, das Sie in dem Computer bekommen, den Sie jetzt benutzen. Verwenden Sie: 

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

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

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

und der ssh-Client wird Sie nicht warnen, da er ihr Gesicht bereits kennt. Er wird die Gesichter jedesmal vergleichen, wenn Sie eine Verbindung herstellen. Das ist sehr wichtig. Im Falle eines Betrügers (z.B. eines Man-in-the-Middle-Angriffs) wird der ssh-Client die Verbindung ablehnen, weil sich das Gesicht geändert haben wird.
Quelle
5
5
5
2014-07-16 15:44:43 +0000

Ich musste lediglich die Textdatei known_hosts in ~/.ssh 

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

erstellen. Danach wurde der Host hinzugefügt, und ich sah die Nachricht nie wieder.
Quelle
2
2
2
2014-12-16 08:23:53 +0000

Es gibt noch einen anderen einfachen Weg: Berühren Sie einfach eine “config”-Datei unter /root/.ssh und fügen Sie den Parameter StrictHostKeyChecking no hinzu. Wenn Sie sich das nächste Mal bei einem Server anmelden, wird der rsa-Schlüssel zu known_hosts hinzugefügt und fragt nicht nach “yes” zur Authentizitätsbestätigung
Quelle
1
1
1
2012-05-05 23:52:02 +0000

Bei dieser Nachricht handelt es sich lediglich um SSH, das Ihnen mitteilt, dass es diesen speziellen Hostschlüssel noch nie zuvor gesehen hat, so dass es nicht in der Lage ist, wirklich zu überprüfen, ob Sie sich mit dem Host verbinden, für den Sie sich halten. Wenn Sie “Ja” sagen, legt es den ssh-Schlüssel in Ihre known_hosts-Datei und vergleicht dann bei nachfolgenden Verbindungen den Schlüssel, den es vom Host erhält, mit dem in der known_hosts-Datei.

Es gab einen verwandten Artikel über Stapelüberlauf, der zeigt, wie diese Warnung deaktiviert werden kann, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .
Quelle
0
0
0
2017-11-04 13:51:11 +0000

Abgesehen von den bereits gegebenen Antworten (Sie haben noch nie eine Verbindung zu diesem Host hergestellt), besteht auch die Möglichkeit, dass Sie noch nie eine Verbindung VOM aktuellen Host (zu diesem Host) hergestellt haben; dies ist nur psychologisch anders; Sie glauben, dass Sie eine Verbindung von Host A (zu B) herstellen, während Sie in Wirklichkeit versuchen, eine Verbindung von Host X (zu B) herzustellen. Dies kann zum Beispiel passieren, wenn Sie zuerst von A nach X ssh-ed und dann vom selben Terminal aus versuchen, von A nach B zu ssh-ed, während Sie denken, dass Sie immer noch auf A sind.
Quelle
0
0
0
2018-05-11 11:03:59 +0000

In meinem Fall funktionierte die kennwortlose Anmeldung aufgrund meiner Berechtigungen für das Home-Verzeichnis nicht, weil ich die Standardeinstellungen geändert habe. Zum Schluss noch Folgendes: Meine Berechtigungen für das Home-Verzeichnis lauten

/home/Benutzername 

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

/home/Benutzername/.ssh 

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

/home/Benutzername/.ssh/autorisiert_keys 

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