SSH: zabezpieczanie zdalnego dostępu

SSH-1, czyli oryginalny protokół Secure Shell, zawierał fundamentalną wadę projektową, która pozwalała aktywnemu atakującemu wstawiać dowolne dane do zaszyfrowanej sesji bez wykrycia. SSH-2, całkowicie przeprojektowany protokół opublikowany w 2006 roku jako RFC 4251-4254, wyeliminował te słabości dzięki rozdzieleniu protokołów warstwy transportowej, uwierzytelniania i połączenia oraz zastosowaniu silniejszego sprawdzania integralności z użyciem HMAC. SSH-1 jest przestarzały i żaden nowoczesny serwer nie powinien go włączać.

Protokół warstwy transportowej SSH obsługuje początkową wymianę kluczy i ustanawia zaszyfrowany kanał chroniony pod względem integralności. Negocjuje algorytmy wymiany kluczy (zazwyczaj ECDH), uwierzytelniania hosta (zazwyczaj Ed25519 lub RSA), szyfrowania symetrycznego (zazwyczaj AES-256-CTR lub ChaCha20-Poly1305) oraz MAC (zazwyczaj HMAC-SHA2-256). Każdy kolejny pakiet jest zarówno szyfrowany, jak i sprawdzany pod kątem integralności za pomocą wynegocjowanych algorytmów.

Po zabezpieczeniu warstwy transportowej warstwa uwierzytelniania użytkownika negocjuje sposób, w jaki użytkownik potwierdza swoją tożsamość serwerowi. Trzy powszechne metody to hasło (użytkownik wpisuje hasło, które jest przesyłane w postaci zaszyfrowanej przez warstwę transportową), klucz publiczny (użytkownik dowodzi posiadania klucza prywatnego odpowiadającego autoryzowanemu kluczowi publicznemu na serwerze) oraz GSSAPI (integracja z jednokrotnym logowaniem Kerberos w środowiskach firmowych).

Warstwa połączenia SSH multipleksuje wiele logicznych kanałów w ramach jednego zaszyfrowanego połączenia transportowego. Typowa sesja SSH ma jeden kanał przeznaczony dla interaktywnej powłoki. Dodatkowe kanały obsługują przekierowanie portów, przekierowanie X11 i transfer plików SFTP, a wszystkie korzystają z tego samego uwierzytelnionego i zaszyfrowanego połączenia. Żądania kanału pozwalają klientowi zażądać pseudoterminala, ustawić zmienne środowiskowe lub wykonać określone polecenie.

Podczas pierwszego łączenia się z serwerem SSH klient otrzymuje klucz hosta serwera i musi zdecydować, czy mu zaufać. Domyślna zasada to Trust On First Use (TOFU): użytkownik jest proszony o zweryfikowanie odcisku klucza (zazwyczaj przedstawionego jako skrót, np. SHA256:...), a po zaakceptowaniu odcisk zostaje zapisany w pliku known_hosts. Przy kolejnych połączeniach zapisany klucz jest porównywany z kluczem przedstawionym przez serwer, a niezgodność powoduje wyświetlenie poważnego ostrzeżenia o możliwym ataku typu man-in-the-middle.

Plik known_hosts, przechowywany w ~/.ssh/known_hosts, zawiera bazę kluczy hostów serwerów indeksowanych nazwą hosta i adresem IP. Każdy wpis łączy adres serwera z jego kluczem publicznym. Jeśli klucz serwera ulegnie zmianie, na przykład z powodu ponownej instalacji serwera albo podszywania się pod niego przez atakującego, SSH odmawia połączenia i wyświetla ostrzeżenie. Administratorzy korzystają z opartego na certyfikatach uwierzytelniania hostów, aby uniknąć decyzji dotyczących zaufania TOFU na dużą skalę.

Uwierzytelnianie za pomocą klucza publicznego polega na zapisaniu klucza publicznego użytkownika w pliku ~/.ssh/authorized_keys na serwerze. Gdy użytkownik się łączy, serwer wysyła wyzwanie zaszyfrowane kluczem publicznym; tylko posiadacz pasującego klucza prywatnego może poprawnie na nie odpowiedzieć, potwierdzając swoją tożsamość bez przesyłania klucza prywatnego ani hasła. Jest to bezpieczniejsze niż hasła, ponieważ klucze prywatne nigdy nie są wysyłane przez sieć i nie można ich wyłudzić metodą phishingu.

W powszechnym użyciu znajdują się trzy rodziny algorytmów kluczy SSH. Klucze RSA o długości 3072 lub 4096 bitów są zgodne ze wszystkimi serwerami. ECDSA z użyciem krzywej NIST P-256 jest szybszy niż RSA przy porównywalnym poziomie bezpieczeństwa, ale parametry bezpieczeństwa krzywej P-256 budzą zastrzeżenia. Ed25519, oparty na algorytmie podpisu cyfrowego wykorzystującym krzywe Edwardsa, jest obecnie zalecanym rozwiązaniem: zapewnia szybkość, niewielkie klucze 256-bitowe, silne właściwości bezpieczeństwa i brak szczególnych wątpliwości dotyczących parametrów.

Tatu Ylönen, fiński badacz z Politechniki Helsińskiej, opracował SSH w 1995 roku po ataku polegającym na przechwytywaniu haseł w sieci swojej uczelni, który ujawnił setki danych uwierzytelniających. Wybrał port 22, ponieważ znajdował się między telnetem (23) a ftp (21). SSH zastąpił oba niezabezpieczone protokoły. Ylönen założył firmę SSH Communications Security, a później opublikował SSH-2 jako otwarty standard za pośrednictwem IETF. OpenSSH, dominująca bezpłatna implementacja, została utworzona przez projekt OpenBSD w 1999 roku.

Agent SSH to proces działający w tle, który przechowuje odszyfrowane klucze prywatne w pamięci, umożliwiając jednokrotne logowanie do wielu serwerów bez ponownego wpisywania hasła. Przekazywanie agenta (flaga -A) rozszerza tę funkcję, przekazując połączenie z agentem do zdalnych serwerów i umożliwiając dostęp do wewnętrznych serwerów przez jeden etap. Przekazywanie agenta stanowi jednak zagrożenie dla bezpieczeństwa: zaatakowany zdalny serwer może użyć przekazanego agenta, aby uwierzytelnić się jako użytkownik na innych serwerach. Zamiast przekazywania agenta należy używać ProxyJump.

Bezpieczna konfiguracja SSH obejmuje wyłączenie logowania roota (PermitRootLogin no), wyłączenie uwierzytelniania hasłem (PasswordAuthentication no) na rzecz logowania wyłącznie za pomocą klucza publicznego, używanie kluczy hosta Ed25519, włączenie tylko protokołu SSH-2, skonfigurowanie limitów czasu bezczynności sesji, ograniczenie dozwolonych użytkowników za pomocą AllowUsers lub AllowGroups oraz zmianę domyślnego portu jako środka zaciemniania, aby ograniczyć szum powodowany przez automatyczne skanowanie. Fail2ban lub podobne narzędzia blokują adresy IP, z których podejmowano wielokrotnie nieudane próby.

Dlaczego uwierzytelnianie SSH za pomocą klucza publicznego jest uznawane za bezpieczniejsze niż uwierzytelnianie za pomocą hasła?

SSH-2 zastąpił wadliwy SSH-1, rozdzielając warstwy transportową, uwierzytelniania i połączenia. Warstwa transportowa negocjuje szyfrowanie i integralność. Uwierzytelnianie użytkownika obsługuje hasła, klucze publiczne i GSSAPI. Weryfikacja klucza hosta korzysta z TOFU i pliku known_hosts. Ed25519 jest zalecanym algorytmem kluczy. Przekazywanie agenta stanowi zagrożenie dla bezpieczeństwa; należy zamiast niego używać ProxyJump. Wzmacnianie zabezpieczeń obejmuje wyłączenie logowania roota i uwierzytelniania hasłem.