Dlaczego uwierzytelnianie za pomocą klucza SSH jest lepsze niż uwierzytelnianie za pomocą hasła?


45

To nie jest tyle pytanie techniczne, co koncepcyjne. Rozumiem, że kryptografia użyta w kluczu SSH jest znacznie silniejsza niż zwykłe hasło, ale nie rozumiem, dlaczego uważa się ją za bezpieczniejszą.

Większość samouczków, które czytam, sugeruje używanie uwierzytelniania za pomocą klucza SSH zamiast uwierzytelniania za pomocą hasła. Rozumiem jednak, że każdy, kto ma dostęp do wstępnie zatwierdzonej maszyny klienckiej, będzie mógł połączyć się z serwerem, co oznacza, że ​​poziom bezpieczeństwa zapewniany przez klucz SSH jest tak silny, jak poziom bezpieczeństwa fizycznego maszyna klienta.

Na przykład, jeśli skonfiguruję klucz SSH w telefonie, aby połączyć się z moim komputerem domowym, jeśli zgubię telefon i ktoś zdoła go odblokować, będzie mógł połączyć się z moim komputerem domowym. Wiem, że mogę następnie usunąć klucz do mojego telefonu z komputera domowego, ale jestem narażony na ryzyko, dopóki nie stwierdzę, że urządzenie klienckie zostało zgubione / naruszone.

Czy coś źle zrozumiałem, czy są to ważne obawy?


10
Wykonaj obie czynności - klucz, który wymaga hasła. W ten sposób musisz zidentyfikować dwie rzeczy, a nie tylko jedną. Możesz również dość łatwo unieważnić utracone klucze i mieć wiele autoryzowanych kluczy, aby uzyskać większą kontrolę nad tym, i tak dalej.
Phoshi

2
Prawdopodobnie powinno to zostać przeniesione do bezpieczeństwa.

10
@DKGasser: Nie, nie powinno. Tutaj pytanie jest całkowicie poprawne. To, że coś można przenieść na inną stronę SE, nie oznacza, że powinno .
Wuffers

4
@DKGasser: To mogła przejść do tej strony, jest to ważna kwestia tam doskonale. Ale jest to również ważne pytanie, więc nie ma powodu, aby je migrować. Jeśli to pytanie zostanie tutaj usunięte z tematu, to tak, można je tam przenieść. Ale jest to całkowicie temat na tej stronie i dlatego nie powinno być migrowane.
Wuffers

3
I nie zapominaj, że klucz SSH nigdy nie przechodzi przez sieć. Serwer zdalny NIGDY nie otrzymuje klucza, w przeciwieństwie do hasła, które jest wysyłane nie tylko przez sieć, ale także na serwer zdalny. Pomyśl o tym następnym razem, gdy nie masz pewności, jakiego hasła użyć, i wypróbuj kilka ... które mogą być używane na innych kontach! Jakie hasła wysłałeś na ten serwer?
9mjb

Odpowiedzi:


40

Jeśli twoja usługa SSH umożliwia uwierzytelnianie oparte na haśle, to połączony z Internetem serwer SSH będzie hamowany w dzień iw nocy przez botnety próbujące odgadnąć nazwy użytkowników i hasła. Sieć botów nie potrzebuje żadnych informacji, może po prostu wypróbować popularne nazwy i popularne hasła. Jest okropnie dużo osób o imieniu John z hasłem qwerty123. Oprócz czegokolwiek innego, to zapycha twoje dzienniki.

Jeśli Twoja usługa SSH umożliwia tylko uwierzytelnianie za pomocą klucza publicznego, osoba atakująca potrzebuje kopii klucza prywatnego odpowiadającego kluczowi publicznemu przechowywanemu na serwerze. Nie mogą po prostu przeprowadzać losowych ataków, muszą mieć wcześniejszą wiedzę o użytkownikach i mieć możliwość kradzieży klucza prywatnego z komputera autoryzowanego użytkownika Twojego serwera SSH.

Fakt, że klucze prywatne są często chronione długim hasłem, ma drugorzędne znaczenie.

Aktualizacja:

Jak wskazują komentarze i jak się przekonałem, przeniesienie usługi SSH z portu 22 do portu o wysokiej liczbie cyfrowej ma ogromną różnicę w liczbie nieautoryzowanych prób logowania pojawiających się w twoich logach. Warto to zrobić, ale uważam to za formę bezpieczeństwa przez zaciemnienie (fałszywe poczucie bezpieczeństwa) - prędzej czy później botnety zaimplementują powolne ukryte skanowanie portów, albo będziesz celowo celowany. Lepiej być przygotowanym.

Zawsze używam długiego hasła do ochrony mojego klucza prywatnego, myślę, że ma to szczególne znaczenie na urządzeniach mobilnych, które można łatwiej zgubić lub skradzić.

Ponadto http://xkcd.com/538/

Bezpieczeństwo


7
+1, z wyjątkiem tego, że autoryzacja klucza publicznego nie zrobi nic, aby twoje dzienniki zostały zablokowane przez boty próbujące się połączyć. Aby temu zapobiec, uruchom serwer SSH na wysokim porcie (tj. 9876 zamiast 22). Następnie, jeśli chcą cię uderzyć, najpierw muszą cię przeskanować, a boty zazwyczaj nie marnują tyle czasu ... jest mnóstwo serwerów SSH na 22.
Ex Umbris

3
Nie żartujesz z rozmiaru dziennika - mój / var / log / secure przeszedł od megabajtów prób logowania do kilobajtów (tylko moje dane logowania).
John C

2
+1 Ciekawe, działam z uwierzytelnianiem opartym na hasłach od… jak 10 lat .. lol .. Oczywiście, moje publicznie ujawnione porty ssh nigdy nie są portem 22. Pomyśl, że botnety skanują mnie i próbują się włamać do każdego port mogą? Dobra informacja, dzięki.
James T Snell

2
@ExUmbris zamiast zmieniać port, należy rozważyć użycie fwknop: Autoryzacja pojedynczego pakietu i Pukanie portów . Korzyści tutaj powinny być oczywiste: jeśli nie pozwolisz nikomu zobaczyć, że port jest otwarty w dowolnym miejscu, chyba że otrzyma dostęp do portu poprzez pukanie w SPA, to nie może nawet spróbować go znaleźć za pomocą nmap i wykorzystaj to. To o wiele lepsze niż zwykłe bezpieczeństwo poprzez zaciemnienie.
aculich

@aculich Zmiana portu nie oznacza „bezpieczeństwa przez zaciemnienie”. Wszystko, co robię, to zapobieganie zapełnianiu się dzienników ostrzeżeniami. Masz jednak rację, mówiąc o poprawie bezpieczeństwa w SPA.
Ex Umbris,

8

Logika jest taka, że ​​istnieje dużo więcej kombinacji kluczy SSH niż haseł, więc trudniej zgadnąć. Korzystanie z kluczy SSH umożliwia także wyłączenie uwierzytelniania hasła, co oznacza, że ​​większość automatycznych ataków przeprowadzanych w Internecie będzie bezużyteczna.

W odniesieniu do bezpieczeństwa fizycznego nie ma różnicy między zapisaniem hasła a posiadaniem niezaszyfrowanego klucza SSH na urządzeniu w przypadku jego zgubienia lub kradzieży. Jedyną korzyścią, jaką możesz mieć, jest to, że nikt nie zna Twojego hasła i możesz teoretycznie upewnić się, że wszystkie urządzenia mają różne certyfikaty SSH, więc możesz po prostu wyłączyć ten dla swojego telefonu.

Uważam, że można również zabezpieczyć hasłem klucze SSH.


Warto jednak zauważyć, że brutalne próby wymuszenia hasła przeciwko sshd można wykryć i zabezpieczyć przed nimi (np. Przez fail2ban), podczas gdy ktoś, kto ukradł twój klucz prywatny, może wypróbować na nim hasła tak szybko, jak pozwoli na to komputer (lub klaster) im. To wciąż nie jest świetny atak , ale drastycznie poprawili swoje szanse w porównaniu z rozsądną polityką fail2ban.
Xiong Chiamiov


1

Hasła mogą być również zagrożone przez monitorowanie klawiatury „nad ramieniem”. Ponadto używanie podobnych haseł w wielu miejscach jest słabością, szczególnie jeśli hasło jest czasami używane na mniej bezpiecznym komputerze z potencjalnymi keyloggerami.

Masz rację, że niezaszyfrowany klucz można odczytać z dysku twardego, jeśli komputer zostanie skradziony - więc zaszyfruj go hasłem.

Jeśli złośliwe oprogramowanie zagraża Twojemu komputerowi, masz problem z zainstalowaniem go niezależnie od tego - ktoś może uzyskać zaszyfrowany klucz i zarejestrować hasło.


1
Uwaga: ale nie możesz zaszyfrować klucza hasłem, jeśli ma być używany programowo (np. W skrypcie).
TheStoryCoder,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.