SSH: Nie można ustalić autentyczności hosta <host>

83

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

Czy jest to po prostu domyślny komunikat, który jest zawsze wyświetlany podczas łączenia się z nowym serwerem?

Przyzwyczaiłem się do tego komunikatu w przeszłości, gdy korzystałem z SSH: zawsze logowałem się hasłem w normalny sposób i czułem się dobrze, ponieważ nie korzystałem z kluczy prywatnych / publicznych (co jest znacznie bezpieczniejsze niż krótkie hasło). Ale tym razem ustawiłem klucz publiczny za pomocą ssh dla mojego połączenia z bitbucket, ale wciąż dostaję wiadomość. Wiem, że podpowiedź hasła na końcu jest innym, dodatkowym środkiem bezpieczeństwa, służącym do odszyfrowania klucza prywatnego.

Mam nadzieję, że ktoś może miło wyjaśnić, co oznacza ten komunikat „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':
Steven Lu
źródło
2
To naprawdę jedna z tych wiadomości „oznacza dokładnie to, co mówi”. Oznacza to, sshże nie ma sposobu, aby powiedzieć, że naprawdę rozmawiasz bitbucket.org. Jeśli skonfigurowałeś jakiś sposób, aby to wiedzieć, to nie działa. Jeśli nie, to znaczy, że nie.
David Schwartz

Odpowiedzi:

71

Mówi ci, że nigdy wcześniej nie łączyłeś się z tym serwerem. Jeśli się tego spodziewałeś, jest to całkowicie normalne. Jeśli jesteś paranoikiem, sprawdź sumę kontrolną / odcisk palca klucza, używając alternatywnego kanału. (Pamiętaj jednak, że osoba, która może przekierować połączenie ssh, może również przekierować sesję przeglądarki internetowej).

Jeśli łączyłeś się wcześniej z tym serwerem z tej instalacji ssh, to albo serwer został ponownie skonfigurowany z nowym kluczem, albo ktoś fałszuje tożsamość serwera. Ze względu na powagę ataku man-in-the-middle ostrzega cię o możliwości.

Tak czy inaczej, masz bezpiecznego szyfrowanego kanału do kogoś . Nikt bez klucza prywatnego odpowiadającego odciskom palca nie 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40może dekodować wysyłanych wiadomości.

Klucz, którego używasz do uwierzytelnienia się, nie jest powiązany ... nie chcesz wysyłać informacji uwierzytelniających do fałszywego serwera, który może je ukraść, więc nie powinieneś oczekiwać żadnych zmian w zależności od tego, czy zamierzasz użyć hasła, czy klucz prywatny do logowania. Po prostu jeszcze nie zaszedłeś tak daleko.

Ben Voigt
źródło
Więc nawet jeśli istnieje złośliwa strona trzecia, a ja odrzucam wiadomość, wszystko, co zamierzam zrobić, to wysłać mu mój klucz publiczny, a on nadal nie będzie w stanie odszyfrować moich danych? Tak więc teraz jedynymi sposobami na narażenie moich danych są: (1) złamanie mojego klucza prywatnego lub (2) złamanie serwerów bitbucket lub (3) złamanie mojego konta bitbucket. Tak długo, jak ograniczają próby zalogowania się (co byłbym naprawdę zaskoczony, gdyby tego nie zrobili), tak naprawdę nie ma zbyt wielu powodów, aby być paranoikiem w tym momencie, co?
Steven Lu
10
@Steven: Nie wysyłasz mu swojego klucza publicznego, on już go ma. To, co robisz, polega na użyciu klucza prywatnego do uwierzytelnienia wyzwania ... jeśli połączył się z prawdziwym bitbucket.org, podając się za ciebie, otrzymał prawdziwe wyzwanie i użył tego wyzwania, gdy cię rzucił, mógł cię oszukać wysyłając mu prawidłową odpowiedź, której używa, aby uzyskać dostęp do twojego konta na prawdziwym bitbucket.org. Nadal nie ma twojego klucza prywatnego, więc nie może zalogować się w przyszłości ani do żadnego innego zasobu, który odblokowuje klucz, ale ma jedną sesję logowania.
Ben Voigt
Właśnie to miałem na myśli, mówiąc: „nie chcesz wysyłać informacji uwierzytelniających do fałszywego serwera”.
Ben Voigt
2
„Jeśli jesteś paranoikiem, sprawdź sumę kontrolną / odcisk palca klucza, używając alternatywnego kanału.” Dla paranoika (i dla przypomnienia ) odcisk palca githuba znajduje się na help.github.com/articles/generating-ssh-keys, a bitbucket jest wymieniony w confluence.atlassian.com/display/BITBUCKET/...
sundar
1
@BenVoigt Tak, rozumiem, że prawdziwie paranoik dostałby się na te strony przez inną niepowiązaną sieć, a może poleciałby do siedziby głównej github i osobiście otrzymał odcisk palca :)
sundar
21

Powiedzmy, że spotykasz się z kimś w celu wymiany tajemnic handlowych. 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 następne spotkania z nim twój doradca nie będzie cię już ostrzegał. To właśnie oznacza wiadomość. Osoba jest zdalnym serwerem, a twoim doradcą jest klient ssh.

Nie sądzę, że paranoikiem jest podwójne sprawdzenie tożsamości osoby przed podzieleniem się z nią sekretami. Na przykład możesz otworzyć stronę internetową ze zdjęciem i porównać ją z twarzą przed sobą. Lub sprawdź jej dowód tożsamości.

W przypadku serwera bitbucket możesz użyć innego, bardziej zaufanego komputera i uzyskać z niego zdjęcie jego twarzy , a następnie porównać go z tym, który masz na komputerze, którego używasz teraz. Posługiwać się:

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

Jeśli twarze pasują do siebie, możesz dodać klucz do pliku np. ~/.ssh/known_hosts(Standardowa lokalizacja w wielu dystrybucjach Linuksa) za pomocą:

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

a klient ssh nie ostrzeże cię, ponieważ zna już jej twarz . Porówna twarze za każdym razem, gdy się połączysz. To bardzo ważne. W przypadku oszusta (np. Ataku man-in-the-middle) klient ssh odrzuci połączenie, ponieważ twarz się zmieni.

Ivan Ogai
źródło
Ta odpowiedź jest bardzo pomocna
010110110101
4
To powinna być zaakceptowana odpowiedź: ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts Dzięki, Ivan!
Rod
1
@Rod: Wybrałbyś zaakceptowaną odpowiedź na podstawie polecenia, które jest całkowicie niepotrzebne (możesz to zmienić known_hosts, wpisując „tak” w oryginalnym ostrzeżeniu, jak pokazano w pytaniu) i niebezpieczne (klucz dodany do twojego plik niekoniecznie jest tym samym, na który spojrzałeś, ponieważ pobrałeś go dwukrotnie!)?
Ben Voigt,
@BenVoigt to, co zapewnia to rozwiązanie, że wpisanie „tak” nie oznacza, że ​​to rozwiązanie jest w pełni skryptowalne. Zakładam, że większość ludzi może dowiedzieć się, jak odpowiedzieć na „(tak / nie)?” skłonić. Natknąłem się na to pytanie podczas próby znalezienia sposobu rozwiązania tego problemu bez interwencji człowieka (w przypadku skryptu konfiguracji serwera). Wydaje mi się, że z podniecenia nie zauważyłem, że pytanie OP jest trochę inne niż moje, ale IMO to wciąż najbardziej użyteczna / nieoczywista odpowiedź w wątku.
Rod
1
@Rod: Nie, to nie jest przydatne. Obniżenie bezpieczeństwa jest złe. Znalezienie szybszych sposobów obniżenia bezpieczeństwa jest dokładnie przeciwne do pożytecznego.
Ben Voigt,
5

Po prostu musiałem utworzyć known_hostsplik tekstowy~/.ssh

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

Po wykonaniu tej czynności dodano hosta i nigdy więcej nie zobaczyłem wiadomości.

Brian
źródło
Nie sądzę, żeby to naprawdę coś zmieniało. Ostrzeżenie jest wyświetlane, gdy sam serwer się zmienił. Na przykład, jeśli udostępnisz nową maszynę wirtualną, z którą łączysz się po raz pierwszy. To, czy masz known_hostsplik (z odpowiednimi uprawnieniami), nie powstrzymuje go przed pytaniem o autentyczność nowego serwera ... Chyba że jakoś już pobrałeś podpis klucza pub dla tego serwera i umieściłeś go na swoim known_hosts, który jest jedynym normalnym sposobem na pominięcie czeku (choć samo stwierdzenie „tak” na czeku jest często szybsze do osiągnięcia tego samego)
Steven Lu
Dzięki. Znałem hostów, ale otrzymywałem ostrzeżenie. Po prostu musiałem zmienić uprawnienia na znane_hosty, aby ostrzeżenia się skończyły.
ArcaneDominion
6
Proszę nie rób tego. Może stanowić poważne zagrożenie bezpieczeństwa. Plik hosta może być zapisywany tylko przez Ciebie. Drugie polecenie pozwala w zasadzie każdemu komputerowi sfałszować tożsamość serwera.
Stolz
„Ostrzeżenie pojawia się, gdy sam serwer się zmienił”. Lub gdy serwer nigdy nie był odwiedzany wcześniej.
Rod
2

Istnieje inny prosty sposób Wystarczy dotknąć pliku „config” w katalogu /root/.ssh i dodać parametr StrictHostKeyChecking no Następnym razem, gdy logujesz się na serwerze, klucz rsa zostanie dodany do znanych_hostów i nie poprosi o „tak” do potwierdzenia autentyczności

Usman
źródło
3
Nie jest to zalecane. Jest to łatwy, ale niewłaściwy sposób radzenia sobie z sytuacją.
Vikas
1

Ta wiadomość po prostu mówi SSH, że nigdy wcześniej nie widział tego konkretnego klucza hosta, więc nie jest w stanie naprawdę zweryfikować, czy łączysz się z hostem, o którym myślisz, że jesteś. Gdy powiesz „Tak”, wstawia klucz ssh do pliku znanego_hosta, a następnie przy kolejnych połączeniach porównuje klucz otrzymany od hosta z kluczem w pliku znanym_hosts.

Powiązany artykuł na temat przepełnienia stosu pokazujący, jak wyłączyć to ostrzeżenie, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .

Mikrofon
źródło
10
Jednak wyłączenie ostrzeżenia nie jest zalecane - służy ono celowi, zapewniając bardzo przydatne informacje dotyczące bezpieczeństwa.
Rory Alsop
0

Oprócz udzielonych już odpowiedzi (nigdy wcześniej nie łączyłeś się z tym hostem), istnieje również wyraźna możliwość, że nigdy wcześniej nie łączyłeś się z bieżącym hostem (z tym hostem); jest to tylko psychologicznie odmienne; myślisz, że łączysz się z hosta A (do B), podczas gdy naprawdę próbujesz połączyć się z hostem X (do B). Może się to na przykład zdarzyć, gdy najpierw ssh-ed z A do X, a następnie z tego samego terminalu spróbuj ssh do B, myśląc, że nadal jesteś na A.

Carlo Wood
źródło
Zastanawiam się, czy użycie przekazywania agenta ssh może również zignorować ostrzeżenie, jeśli host A wie o B, ale X nie, ale przekazywanie agenta odbywa się między A i X. Większość środowisk (które zapewniają ssh) i aplikacje terminalowe obsługują przekazywanie agentów, pomaga ogranicz liczbę kluczy ssh, którymi musisz zarządzać tylko na urządzeniach końcowych.
Steven Lu
0

W moim przypadku hasło bez logowania nie działało z powodu moich uprawnień do katalogu domowego, ponieważ zmieniłem ustawienia domyślne. Wreszcie, oto co dla mnie zadziałało. moje uprawnienia do katalogu domowego to

/ home / nazwa użytkownika

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
Mian Asbat Ahmad
źródło