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

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.

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.

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.

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.

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 .

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.

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