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

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

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.

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.

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.

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

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 .

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.

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