Uzgadnianie SSH i uwierzytelnianie kluczem hosta

SSH rozpoczyna się od połączenia TCP z portem 22. Po jego ustanowieniu klient i serwer wymieniają ciągi wersji, takie jak SSH-2.0-OpenSSH_9.3, które identyfikują wersję protokołu i implementację. Ta wymiana wersji pozwala obu stronom potwierdzić zgodność przed przejściem dalej.

Po wymianie wersji obie strony wysyłają pakiety SSH_MSG_KEXINIT zawierające listy obsługiwanych algorytmów. Listy te obejmują metody wymiany kluczy, typy kluczy hosta, szyfry symetryczne, algorytmy MAC i kompresję. Część wspólna obu list określa algorytmy wybrane dla sesji.

Klucz sesji jest ustanawiany za pomocą algorytmu wymiany kluczy, takiego jak Diffie-Hellman lub ECDH. Klient i serwer generują efemeryczne pary kluczy, wymieniają wartości publiczne i niezależnie obliczają ten sam wspólny sekret. Ten wspólny sekret służy jako podstawa wyprowadzania klucza sesji, ale nigdy nie jest przesyłany bezpośrednio.

Serwer potwierdza swoją tożsamość, podpisując skrót wymiany kluczy za pomocą prywatnego klucza hosta. Klucz hosta może być kluczem RSA, ECDSA albo nowoczesnym kluczem Ed25519. Klient używa odpowiadającego mu klucza publicznego do weryfikacji tego podpisu, potwierdzając, że komunikuje się z prawdziwym serwerem, a nie z oszustem.

Przy pierwszym połączeniu z nowym serwerem klient nie zna jeszcze publicznego klucza hosta. SSH wyświetla odcisk klucza i prosi użytkownika o jego zaakceptowanie. Model Trust On First Use przechowuje klucz w known_hosts i wykrywa zmiany przy kolejnych połączeniach, ostrzegając o możliwych atakach typu man-in-the-middle.

Najbezpieczniejszym sposobem weryfikacji nowego klucza hosta serwera jest użycie niezależnego kanału. Administrator może odczytać odcisk klucza osobiście lub za pośrednictwem zweryfikowanego bezpiecznego kanału, a następnie porównać go z odciskiem wyświetlanym przez klienta SSH. Zapobiega to cichemu zaakceptowaniu fałszywego klucza przy pierwszym połączeniu.

Plik known_hosts przechowuje wiersze w postaci: hostname algorithm base64-key comment. Każdy wpis reprezentuje zaufaną tożsamość serwera. Podczas łączenia z hostem znajdującym się już w known_hosts SSH sprawdza, czy przedstawiony klucz odpowiada zapisanemu, i odrzuca połączenie w przypadku niezgodności.

Po wymianie kluczy obie strony niezależnie wyprowadzają klucze sesji na podstawie wspólnego sekretu, skrótu wymiany i identyfikatora sesji. Osobne klucze są wyprowadzane dla każdego kierunku komunikacji oraz oddzielnie na potrzeby szyfrowania i operacji MAC. Oznacza to, że klucze używane do ruchu od klienta do serwera różnią się od kluczy używanych do ruchu od serwera do klienta.

Po ustanowieniu kluczy sesji cała dalsza komunikacja SSH jest szyfrowana i uwierzytelniana. Wynegocjowany szyfr, taki jak AES-256-GCM lub ChaCha20-Poly1305, zapewnia poufność, a algorytm MAC gwarantuje integralność. Nawet nazwa użytkownika i dane uwierzytelniające są przesyłane wewnątrz tego zaszyfrowanego tunelu.

Klucze hosta RSA o długości 2048 lub 4096 bitów są szeroko obsługiwane, ale działają wolniej. Klucze ECDSA oparte na krzywych NIST są szybsze, lecz niektórzy nie ufają parametrom krzywych NIST. Klucze Ed25519 oparte na Curve25519 są obecnie zalecane: są niewielkie, szybkie, zapewniają wysoki poziom bezpieczeństwa i nie zależą od parametrów krzywych NIST. Większość nowoczesnych serwerów SSH domyślnie oferuje Ed25519.

Uzgadnianie SSH obejmuje: nawiązanie połączenia TCP, wymianę wersji, negocjację algorytmów, wymianę kluczy ustanawiającą klucze sesji, weryfikację klucza hosta serwera oraz uwierzytelnianie użytkownika. Wszystkie kroki po wymianie wersji odbywają się w zaszyfrowanym kanale chronionym przed naruszeniem integralności, ustanowionym podczas fazy wymiany kluczy.

Jak klient weryfikuje klucz hosta serwera SSH przy kolejnych połączeniach po pierwszym połączeniu?

W tej lekcji: połączenie TCP jest nawiązywane na porcie 22, następuje wymiana ciągów wersji, negocjacja algorytmów wybiera szyfry i metody wymiany kluczy, ECDH lub DH ustanawia wspólny sekret, klucze sesji są wyprowadzane osobno dla każdego kierunku, serwer uwierzytelnia się za pomocą podpisu klucza hosta, a klient weryfikuje go względem known_hosts, korzystając z modelu TOFU przy pierwszym połączeniu.