Czy twoje hasło SSH jest ujawniane, gdy próbujesz połączyć się z niewłaściwym serwerem?

192

Czy podczas próby przypadkowego połączenia się z niewłaściwym serwerem przy użyciu poświadczeń hasła administrator może odczytać i zalogować hasło, którego użyłeś?

ssh password

— vfclists
źródło

11

Czy uwierzytelnianie hasłem SSH zapewnia hasło dla serwera?

— jamesdlin

41

W kliencie ssh najpierw uwierzytelniasz serwer i robisz to, mówiąc: „Ufam, że mogę podać moje hasło do tego serwera”. Następnym razem zwróć większą uwagę na wiadomość, którą zobaczyłeś jako pierwszą: „Nie można ustalić autentyczności X. Odcisk palca klucza RSA to Y Czy jesteś pewien, że Z? (Tak / nie)” To irytujące pytanie nie byłoby zadawane, gdybyś przypuszczał automatyczna odpowiedź tak za każdym razem.

— kubańczyk

6

Możliwe jest ustawienie PasswordAuthentication nodomyślne w OpenSSH i włączenie go (tylko / w razie potrzeby) dla zaufanych serwerów. W połączeniu ze ścisłym sprawdzaniem klucza hosta powinno to przede wszystkim chronić cię przed ujawnieniem hasła, oczywiście kosztem wygody.

— hobbs

6

@Kubańczyk, jeśli chcesz połączyć się z SSH pod adresem „internal-www.my-company.com”, ale przypadkowo wpisałeś „ssh www.my-company.com”, ten monit nie ochroni cię - prawdopodobnie oba serwery są na zaufanej liście, po prostu jedna z nich jest prowadzona przez ciebie, a druga przez stronę trzecią.

— Mark

@ Hobbs ChallengeResponseAuthentication noteż, myślę

— ilkkachu

215

Mówiąc prosto: tak

Więcej szczegółów...

Jeśli łączysz się z moją maszyną, nie wiesz, czy działam na normalnym sshserwerze, czy na serwerze, który został zmodyfikowany w celu zapisania przekazywanego hasła.

Co więcej, niekoniecznie musiałbym modyfikować sshd, ale mógłbym napisać moduł PAM (np. Używając pam_script), który przekaże twoje hasło.

Więc tak. NIGDY nie wysyłaj hasła do niezaufanego serwera. Właściciel urządzenia mógł łatwo skonfigurować go do rejestrowania wszystkich prób hasła.

(W rzeczywistości nie jest to rzadkie w świecie infosec; skonfiguruj serwer typu plaster miodu, aby rejestrować próbowane hasła)

— Stephen Harris
źródło

13

Poprawny. Domyślnie średnia sshdnie nie zalogować haseł. (Jeśli podasz hasło jako nazwę logowania, zostanie ono zarejestrowane, ale to kolejny problem). Standard sshdjest narzędziem bezpieczeństwa, więc nie rejestruje takich poświadczeń :-)

— Stephen Harris

116

Jeszcze jeden powód, aby używać par kluczy publiczny / prywatny ...

— gerrit

3

Od jakiegoś czasu zastanawiam się nad użyciem haseł, a ostatnio przyszło mi do głowy, że próba zalogowania się na niewłaściwe serwery byłaby dobrym sposobem na ujawnienie mojego hasła złośliwemu administratorowi serwera.

— vfclists

10

@vfclists logujący się na niewłaściwy serwer jest również dokładnie powodem, dla którego klient sshd przechowuje odcisk palca dla każdego serwera. Kiedy łączysz się po raz pierwszy, akceptujesz ten odcisk palca, a następnie, jeśli się nie zgadza, otrzymujesz gigantyczne ostrzeżenie, na które powinieneś zwrócić uwagę.

— hometoast

44

Lepsza rada: nigdy nie używaj uwierzytelniania hasła dla ssh. Protokół ma autoryzację klucza publicznego z bardzo dobrych powodów; Użyj tego!

— R ..

52

Tak.

Hasło jest wysyłane po ustanowieniu szyfrowanego połączenia, ale serwer zdalny otrzymuje hasło w postaci zwykłego tekstu.

Jeśli Ci na tym zależy, najlepszym i najłatwiejszym rozwiązaniem jest użycie kluczy SSH.

Jeśli masz maszyny, które nie akceptują kluczy, jednym z rozwiązań byłoby utworzenie narzędzia, które bezpiecznie przechowuje hasła, a następnie używa sshpassdo wysyłania prawidłowego hasła w zależności od serwera, z którym się łączysz.

Powodem, dla którego hasło jest wysyłane w postaci zwykłego tekstu, jest to, że pozostawia wszystkie decyzje dotyczące obsługi i przechowywania go na odległym końcu, a klient może być całkowicie głupi. Istnieje kilka różnych formatów haszowania (przechowywania) haseł używanych w systemach Linux i BSD w ciągu ostatnich dziesięciu lat ( crypt (3) ), z których żaden nie wymaga wsparcia ze strony klienta.

Chociaż częściowo wynika to również z historii (tj. Zawsze tak było). Istnieją lepsze protokoły uwierzytelniania typu wyzwanie-odpowiedź, których można używać nawet w przypadku haseł. Na przykład SRP , który zapewnia stronom wspólny sekret podczas uwierzytelniania. Został zaimplementowany dla niektórych serwerów SSH, ale łatka dla OpenSSH dotyczy (bardzo) starej wersji.

— ilkkachu
źródło

1

Problem z protokołami odpowiedzi na wyzwanie dla uwierzytelniania hasła polega na tym, że niektóre z nich wymagają od serwera przechowywania hasła w postaci zwykłego tekstu. Jeśli protokół wyzwanie-odpowiedź zezwala serwerowi na przechowywanie zaszyfrowanego hasła, najprawdopodobniej wymaga bardzo określonego algorytmu mieszającego.

— kasperd

8

Hasła są generalnie wysyłane w postaci „zwykłego tekstu” (tzn. Nie w formie jawnej, ale tylko z ochroną zapewnianą przez SSH | TLS | cokolwiek połączenie zapewnia). Jeśli system wezwał do hashowania po stronie klienta i hasha do wysłania, serwery nie miałyby możliwości uzyskania rzeczywistego hasła, a zamiast tego przyznałyby dostęp każdemu, kto mógłby podać hash , czyniąc wymieniony hash równoważnym .

— Blacklight Shining

1

@BlacklightShining Potwierdzenia hasła zerowej wiedzy istnieją, ale nie są używane w SSH, ponieważ nie ma sposobu, aby użyć dla nich standardowej bazy danych haseł i nie ma sensu używać ich zamiast uwierzytelniania opartego na kluczach.

— Random832

gdzie mogę zobaczyć hasła użyte do uwierzytelnienia? Nie ma ich w /var/log/auth.log, a gdzie?

— アレックス

OpenSSH nie będzie rejestrować haseł, nie powiodło się lub w inny sposób. (Nie znam się zbyt dobrze na innych serwerach SSH.) W prawie wszystkich legalnych instalacjach, jakąkolwiek wartość, jaką może to zapewnić, przeważałoby ryzyko nieodłącznie związane z celowym rejestrowaniem haseł - niektóre z nich mogły zostać dostarczone przez legalnych użytkowników, którzy popełniali literówkę lub wypróbowałem niepoprawne, ale właściwe dla czegoś innego hasło - w postaci czystego tekstu. Jeśli masz dobry powód, by to zrobić, łatanie łatki OpenSSH byłoby łatwe.

— musicinmybrain

10

Aby zbudować na podstawie odpowiedzi Stephena Harrisa, oto widok w czasie rzeczywistym, który zbudowałem, który pokazuje, co zmodyfikowany skrypt uwierzytelniania PAM byłby w stanie przechwycić, łącząc się z urządzeniem przez ssh (rodzaj plastra miodu). Używam zmodyfikowanej wersji biblioteki PAM lib-storepw.

https://livesshattack.net

https://livesshattack.net/about

— Willie S.
źródło

4

Odpowiedzi, które są przede wszystkim linkami, są niezadowolone w przypadku, gdy link stanie się niedostępny (brzmi to tak, jakbyś utrzymywał tę stronę osobiście, ale nadal). Powinieneś opisać, w jaki sposób poradziłeś sobie z tym za pomocą skryptu uwierzytelniania dla czytelników.

— Centimane

już nie działa, wysłałem ogromny ciąg znaków jako hasło, myślę, że mógł go złamać, przepraszam: - /

— scottydelta

@ scottydelta Chociaż nie zaglądałem do niego, może istnieć limit bufora dla rozmiaru hasła, który moduł PAM lub sam demon SSH może zaakceptować podczas próby uwierzytelnienia. Witryna nadal działa tak, jak zamierzałem, aczkolwiek poradzi sobie z limitem bufora zaakceptowanym przez sshd lub moduł PAM, jeśli rzeczywiście tak jest.

— Willie S.

Nie interesuje Cię źródło zmodyfikowanej biblioteki lib-storepw, z którego mogą korzystać inni?

— Tim Fletcher,

2

SSH to protokół, który wymaga wzajemnego zaufania. To jest powód, dla którego klient OpenSSH utrzymuje plik znany_hosty, aby wdrożyć swoje zaufanie przy pierwszym użyciu.

Podczas próby zalogowania się na serwerze SSH, niezależnie od tego, kto dostarczył oprogramowanie lub jakie dane ma skonfigurować do rejestrowania, bierzesz udział w pewnej procedurze uwierzytelniania. Korzystając z uwierzytelniania hasła, przesyłasz swoje hasło na ten serwer. Jest to jeden z powodów, dla których zaleca się kryptografię asymetryczną (klucz publiczny, certyfikaty) - kryptografia klucza publicznego znacznie zmniejsza ryzyko ujawnienia poświadczeń. (Chociaż może to nie chronić cię przed atakiem MitM, jeśli używasz przekazywania ssh-agent lub podobnego schematu.)

— jvoorhis
źródło

SSH nie wymaga wzajemnego zaufania, a przynajmniej nie symetrycznego zaufania. Ważne jest, aby być precyzyjnym: znane_hosty dotyczą autentyczności, a nie zaufania. Jak zauważyłeś, umieszczenie klucza publicznego na mniej zaufanym hoście jest bezpieczne. Rzeczywiście, używanie hasła do logowania jest również „bezpieczne”, zakładając, że nie użyjesz go ponownie. (Jest to oczywiście tak bezpieczne, jak stopień zaufania do serwera.) Nawet loginy ssh oparte na hoście zależą od zaufania asymetrycznego.

— markhahn