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

SSH: Autentyczność hosta nie może być ustalona

Co oznacza ta wiadomość? Czy jest to potencjalny problem? Czy kanał nie jest bezpieczny?

Czy jest to po prostu domyślna wiadomość, która jest always wyświetlana podczas łączenia się z nowym serwerem?

Jestem przyzwyczajony do oglądania tej wiadomości podczas używania SSH w przeszłości: Zawsze podawałem swój login z hasłem w normalny sposób i czułem się z tym dobrze, ponieważ nie korzystałem z kluczy prywatnych/publicznych (co jest znacznie bezpieczniejsze niż krótkie hasło). Ale tym razem skonfigurowałem klucz publiczny z ssh dla mojego połączenia z bitbucketem, ale nadal otrzymałem wiadomość. Zdaję sobie sprawę, że podpowiedź hasła na końcu jest innym, dodatkowym zabezpieczeniem, służącym do rozszyfrowania klucza prywatnego.

Mam nadzieję, że ktoś da mi ładne wyjaśnienie, co oznacza ta wiadomość “nie można ustalić autentyczności”.

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':

Odpowiedzi (7)

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

Mówi ci to, że nigdy wcześniej nie łączyłeś się z tym serwerem. Jeśli się tego spodziewałeś, to jest to zupełnie normalne. Jeśli masz paranoję, sprawdź sumę kontrolną/odcisek palca klucza za pomocą alternatywnego kanału. (Ale pamiętaj, że ktoś, kto może przekierować Twoje połączenie ssh, może również przekierować sesję przeglądarki internetowej)

Jeśli połączyłeś się z tym serwerem wcześniej z tej instalacji ssh, to albo serwer został przekonfigurowany z nowym kluczem, albo ktoś przechwytuje tożsamość serwera. Ze względu na powagę ataku typu “man-in-the-middle”, jest to ostrzeżenie o takiej możliwości.

Tak czy inaczej, masz bezpieczny szyfrowany kanał do somebody. Nikt bez klucza prywatnego odpowiadającego odciskowi palca 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 nie jest w stanie zdekodować tego, co wysyłasz.

Klucz, którego używasz do uwierzytelnienia się, jest niepowiązany… nie chciałbyś wysyłać informacji o uwierzytelnieniu do oszukańczego serwera, który mógłby je ukraść, więc nie powinieneś oczekiwać żadnych zmian w zależności od tego, czy do logowania masz zamiar użyć hasła, czy klucza prywatnego. Po prostu jeszcze nie doszedłeś tak daleko w tym procesie.

23
23
23
2016-08-10 11:42:38 +0000

Powiedzmy, że spotykasz się z kimś, żeby wymienić jakieś tajemnice biznesowe. Twój doradca mówi Ci, że nigdy wcześniej nie spotkałeś tej osoby i że może to być oszust. Co więcej, na kolejne spotkania z nim Twój doradca nie będzie Cię już ostrzegał. To właśnie oznacza wiadomość. Osoba ta jest zdalnym serwerem, a Twój doradca jest klientem ssh.

Nie sądzę, aby paranoikiem było podwójne sprawdzanie tożsamości tej osoby przed podzieleniem się z nią tajemnicami. Możesz na przykład otworzyć stronę internetową z jej zdjęciem i porównać je z twarzą przed sobą. Albo sprawdzić jej dowód osobisty.

Dla serwera Bitbucket, można użyć innego, bardziej zaufanego komputera i uzyskać obraz jej twarzy z niego, a następnie porównać go z tym, który masz w komputerze, którego używasz teraz. Użyj:

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

Jeśli faces pasuje, możesz dodać klucz do pliku np. ~/.ssh/known_hosts (standardowa lokalizacja w wielu dystrybucjach Linuksa) z:

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

a klient ssh nie ostrzeże cię jak już wie her face. Będzie porównywać the faces za każdym razem gdy się połączysz. To jest bardzo ważne. W przypadku szarlatana (np. atak człowieka w środku), klient ssh odrzuci połączenie, ponieważ face się zmieni.

5
5
5
2014-07-16 15:44:43 +0000

Po prostu musiałem stworzyć plik tekstowy known_hosts w ~/.ssh

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

Po wykonaniu tej czynności, dodał on hosta i już nigdy nie widziałem tej wiadomości.

2
2
2
2014-12-16 08:23:53 +0000

Jest jeszcze jeden prosty sposób Po prostu dotknij pliku “config” pod /root/.ssh i dodaj parametr StrictHostKeyChecking no Następnym razem, gdy zalogujesz się na serwer, klucz rsa zostanie dodany do znanych _hosts i nie będzie pytał o “tak” dla potwierdzenia autentyczności.

1
1
1
2012-05-05 23:52:02 +0000

Ta wiadomość to tylko SSH mówiący, że nigdy wcześniej nie widział tego konkretnego klucza hosta, więc nie jest w stanie naprawdę zweryfikować, że łączysz się z hostem, za jakiego się uważasz. Kiedy powiesz “Tak”, włoży klucz ssh do znanego nam pliku _hosts, a następnie przy kolejnych połączeniach porówna klucz, który otrzymuje od hosta z tym, który znajduje się w znanym pliku _hosts.

Był związany z tym artykuł o przepełnieniu stosu, pokazujący jak wyłączyć to ostrzeżenie, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .

0
0
0
2017-11-04 13:51:11 +0000

Oprócz już udzielonych odpowiedzi (nigdy wcześniej nie łączyłeś się z tym gospodarzem), istnieje również wyraźna możliwość, że nigdy wcześniej nie łączyłeś się z obecnym gospodarzem (z tym gospodarzem); jest to tylko różnica psychologiczna; myślisz, że łączysz się z gospodarza A (do B), podczas gdy tak naprawdę starasz się łączyć z gospodarza X (do B). Może się to zdarzyć na przykład wtedy, gdy najpierw ssh-ed z A do X, a następnie z tego samego terminalu próbujesz ssh do B, myśląc, że nadal jesteś na A.

0
0
0
2018-05-11 11:03:59 +0000

W moim przypadku hasło less login nie działało z powodu moich uprawnień do katalogu domowego, ponieważ zmieniłem ustawienia domyślne. Na koniec, oto co mi się udało. moje uprawnienia do katalogów domowych to

/home/username

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