Dlaczego powinienem używać uwierzytelniania klucza publicznego dla SSH?

Korzystam z serwera SSH i nadal używam prostego uwierzytelniania hasłem. Wszędzie, gdzie czytam o bezpieczeństwie, zaleca się korzystanie z uwierzytelniania klucza publicznego. Ale nie mam zalet. Używanie ich jest, moim zdaniem, niepewne lub wymaga dużo pracy.

Oczywiście, jeśli ktoś spróbuje brutalnie wymusić logowanie do mojego serwera SSH, klucz publiczny jest znacznie silniejszy niż jakiekolwiek hasło. Ale poza tym jest całkowicie niepewny.

Doradcy najczęściej twierdzą, że nie musisz pamiętać hasła. Jak niebezpieczne to jest? Więc jeśli ktoś włamie się na mój komputer, nie tylko dostanie mój komputer, ale także mój serwer? Jeśli używam SSH od różnych klientów, muszę przechowywać klucze publiczne po jednym dla każdego z nich, co zwielokrotnia prawdopodobieństwo, że wpadną w fałszywe ręce. Mógłbym zapisać je na pendrivie, który noszę ze sobą, ale można go zgubić, a wyszukiwarka ma dostęp do mojego serwera.

Być może lepiej służy mi uwierzytelnianie dwuskładnikowe.

Czy brakuje mi argumentu? Jaki jest dla mnie najlepszy sposób?

jeśli ktoś włamie się na mój komputer, nie tylko dostanie mój komputer, ale także mój serwer?

Jest to potencjalnie prawda w przypadku keyloggerów: gdy tylko zalogujesz się do swojego serwera z zainfekowanego komputera, otrzymają hasło.

Ale klucze mają 3 zalety:

1) Uwierzytelnianie w pamięci podręcznej. Wprowadź hasło raz, wykonaj wiele poleceń ssh. Jest to bardzo przydatne, jeśli używasz czegoś, co używa ssh jako transportu, takiego jak scp, rsync lub git.

2) Uwierzytelnianie skalowalne. Wpisz swoje hasło raz, zaloguj się na wiele komputerów . Im więcej posiadasz maszyn, tym bardziej jest to przydatne. Jeśli masz 100 maszyn, co robisz? Nie możesz użyć tego samego hasła (chyba że jest to farma klonów) i nie pamiętasz tylu. Musisz więc użyć menedżera haseł i wrócić do jednego kompromisu. Skutecznie kluczem hasło jest Twój menedżer haseł.

2b) Skaluje się w drugą stronę, jeśli masz wielu administratorów korzystających z tych samych systemów, ponieważ możesz odwołać klucze od użytkownika A bez konieczności informowania B, C, D, E, F ... o zmianie hasła.

(Można to również zrobić z indywidualnymi kontami i sudo, ale wtedy trzeba je jakoś uzupełnić)

3) Automatyzacja i częściowe przekazanie uprawnień. Możesz skonfigurować SSH, aby uruchamiał określone polecenie, gdy łączy się klucz . Umożliwia to zautomatyzowanemu procesowi w systemie A zrobienie czegoś w systemie B bez pełnego zaufania między nimi bez hasła.

(Jest to zamiennik rlogin / rsh, który był przezabawnie niepewny)

Edycja: kolejną zaletą kluczy publicznych zamiast haseł jest powszechny scenariusz, w którym serwer jest narażony na atak przez lukę. W takim przypadku zalogowanie się przy użyciu hasła powoduje natychmiastowe złamanie hasła. Logowanie za pomocą klucza nie! Powiedziałbym, że jest to częstsze niż narażanie się na atak administratora.

Jeśli używasz dobrych haseł, może to być wystarczająco bezpieczne. Zazwyczaj ograniczam liczbę publicznie dostępnych serwerów do minimum i zezwalam na SSH z określonych adresów IP, o ile to możliwe.

Możesz także chronić swoje klucze hasłem (hasłem). Hasło to należy wprowadzić zawsze, gdy konieczne jest zalogowanie się na serwerach. Nikt nie może wtedy użyć Twojego klucza, chyba że podasz odpowiednie hasło.

Istnieją podobne posty:

1. Prześlij z błędu serwera .
2. Prześlij z wymiany stosu zabezpieczeń .
3. Post od administratora .

Jednym ze sposobów, w którym autoryzacja klucza publicznego jest bardziej bezpieczna, jest to, że osoba atakująca udaje się w stanie man-in-the-middle (MitM) między komputerem klienckim a serwerem i nie zauważasz zmieniającego się klucza hosta (prawdopodobnie dlatego, że nie zrobiłeś tego nie mają starego klucza, np. ponieważ po raz pierwszy używam tego konkretnego komputera klienckiego).

(To samo dotyczy sytuacji, gdy osoba atakująca zdoła przejąć kontrolę nad serwerem, a istnieją inne serwery, na których działają te same dane uwierzytelniające).

W przypadku standardowego uwierzytelniania opartego na haśle hasło jest przesyłane (wewnątrz szyfrowanego połączenia) zwykłym tekstem, prawdziwy serwer zwykle je haszuje i porównuje wynik z hashem przechowywanym w bazie danych haseł. Atakujący MitM może zamiast tego wziąć to hasło, otworzyć połączenie z prawdziwym serwerem i zalogować się tam ... i albo przekazać Ci zawartość (żebyś nic nie zauważył), albo po prostu zrobić swoje własne złe rzeczy na twoim serwerze .

W przypadku uwierzytelniania za pomocą klucza publicznego klient zasadniczo podpisuje niektóre dane znane zarówno serwerowi, jak i klientowi, aby udowodnić, że posiada klucz prywatny, i wysyła podpis na serwer. Te podpisane dane zawierają identyfikator sesji, który zależy od liczb losowych wybranych zarówno przez klienta, jak i serwer, a zatem jest różny dla każdej sesji. Jeśli MitM otworzy własne połączenie SSH z prawdziwym serwerem, będzie ono miało inny identyfikator sesji, a zatem podpis podany przez klienta nie będzie tam działał.

Oczywiście, jak już powiedziano w innych odpowiedziach, musisz zabezpieczyć swój klucz prywatny, np. Zaszyfrowany hasłem lub ewentualnie na oddzielnym urządzeniu, które tworzy podpisy dopiero po wprowadzeniu kodu PIN.

OpenSSH może zachować własny urząd certyfikacji do zarządzania kluczami hosta i klienta SSH i może używać na nich list odwołania. Może to zwiększyć bezpieczeństwo zapewniane przez uwierzytelnianie oparte na kluczach.

Masz rację co do roszczenia „nie potrzebujesz hasła”. To jest naprawdę niepewne po stronie klienta.

Tym, co pozwala na znacznie bezpieczniejsze logowanie tylko kluczy publicznych, jest fakt, że nie ma sposobu na brutalny dostęp do twojego serwera. Jedyne, co może osiągnąć atakujący, to obciążenie twojego serwera - możesz użyć fail2ban, aby utrzymać to pod kontrolą.

Dla bezpieczeństwa po stronie klienta należy chronić klucz prywatny za pomocą dobrego hasła. Oczywiście teraz łączenie się z serwerem jest bardziej kłopotliwe niż przy użyciu hasła. Aby temu zaradzić, możesz użyć agenta ssh do przechowywania klucza prywatnego w pamięci, jeśli zamierzasz połączyć się z serwerem kilka razy z rzędu. Dobrą praktyką jest ograniczenie czasu, przez jaki klucz powinien być przechowywany w pamięci.

Być może lepiej służy mi uwierzytelnianie dwuskładnikowe.

Jedną z możliwości 2FA dla SSH (i taką, która wymaga stosunkowo niewielkiej konfiguracji / złożoności) jest użycie klucza publicznego i hasła.

Uważam, że AuthenticationMethods publickey,keyboard-interactivemożna dodać coś podobnego /etc/ssh/sshd_configdo tego, aby to zadziałało.

Mówiąc bardziej ogólnie, problemem jest to, że hasła (same) nie są świetną metodą uwierzytelniania, ponieważ często mają wątpliwą jakość. Bardzo prosty „argument” dla kluczy a haseł polega na tym, że klucz będzie miał co najmniej 2048 bitów, a często więcej (w przypadku kluczy EC byłaby to siła efektywna, a nie rzeczywisty rozmiar). Te bity są również generowane przez kryptologicznie bezpieczny (lub odpowiedni) mechanizm.

Hasło ma często mniej niż 2048 bitów i często nie pochodzi z kryptograficznie bezpiecznego źródła.

Możesz także zabezpieczyć klucze hasłem, aby uchronić się przed problemami związanymi z ich utratą (chociaż ktoś może spróbować brutalnie wymusić to hasło).

Zasadniczo różnice między kluczami i hasłami można uczynić dość przejrzystymi, a używanie kluczy zapewnia lepsze hasło niż człowiek. Nie oznacza to, że są panaceum, ale średnio zapewniają większe bezpieczeństwo niż hasła.