Postkwantowe SSH w Ubuntu: jak sprawdzić konfigurację

Co zmieniło się w postkwantowym SSH

Postkwantowe SSH jest już domyślnie włączone dla większości użytkowników i nie wymagało żadnej konfiguracji. Obecny klient OpenSSH komunikujący się z aktualnym serwerem OpenSSH wybiera domyślnie hybrydową wymianę kluczy postkwantowych. Dzięki temu klucz sesji jest odporny na ataki polegające na rejestrowaniu ruchu dzisiaj w celu jego odszyfrowania w przyszłości. Ochrona ta jest rzeczywista, choć węższa, niż sugeruje określenie "SSH odporne na komputery kwantowe".

Najpierw wyjaśnijmy dwa terminy. SSH (secure shell) to protokół używany do logowania się na serwer. Wymiana kluczy, często określana jako "kex", jest pierwszym etapem każdego połączenia SSH: obie strony uzgadniają wspólny sekret, który szyfruje całą dalszą komunikację. Zmianie uległa wyłącznie wymiana kluczy. Nic innego nie uległo zmianie.

Nie ufaj tej stronie, uruchom polecenia

Każda nazwa algorytmu poniżej pochodzi z polecenia, które można wykonać samodzielnie. Jest to zamierzone działanie. Wartości domyślne zmieniają się wraz z każdym wydaniem OpenSSH, więc poradnik napisany dwa lata temu wymienia algorytm, którego Twoja maszyna już nie preferuje, a nie ma ona możliwości, aby Cię o tym powiadomić. Naucz się tych poleceń, a przestaniesz potrzebować artykułów na ten temat, w tym również tego.

Zacznij od sprawdzenia możliwości Twojej kompilacji.

ssh -V
ssh -Q kex

ssh -V wyświetla linię wersji zaczynającą się od OpenSSH_, po której następuje sufiks pakietu Ubuntu oraz wersja OpenSSL. ssh -Q kex wyświetla jeden algorytm wymiany kluczy w każdej linii. W kompilacji z obsługą post-quantum znajdziesz na tej liście nazwy takie jak mlkem768x25519-sha256 oraz sntrup761x25519-sha512@openssh.com, umieszczone obok klasycznych nazw, takich jak curve25519-sha256.

To, co wspiera kompilacja, różni się od tego, co jest oferowane

To rozróżnienie, które pomija większość publikacji. ssh -Q kex odpowiada na jedno pytanie: co ten plik binarny potrafi zrobić. Nie odpowiada na pytanie, które jest istotne: co faktycznie zaproponuje to połączenie. Te dwie listy są różne, a różnica między nimi to miejsce, w którym przestarzałe porady wyrządzają realne szkody.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> wyświetla efektywną konfigurację klienta dla danego hosta, po zastosowaniu ~/.ssh/config oraz /etc/ssh/ssh_config. sshd -T robi to samo dla serwera. Każde z nich wypisuje pojedynczą linię kexalgorithms w kolejności preferencji, a pierwsza nazwa na niej jest pierwszym wyborem danej strony. Ta linia jest przesyłana przez sieć.

Ta różnica nie jest teoretyczna. OpenSSH 8.5, wydany 2021-03-03, dodał sntrup761x25519-sha512@openssh.com i celowo pominął go na domyślnej liście. W tym wydaniu ssh -Q kex pokazuje ten algorytm, a ssh -G nie, co oznacza, że plik binarny może wykonać postkwantową wymianę kluczy, ale żadne połączenie o to nie prosi.

Odczyt algorytmu wynegocjowanego przez połączenie

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Pomiędzy bieżącym klientem a bieżącym serwerem wyświetla się:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 to rozwiązanie hybrydowe. Uruchamia ono ML-KEM (mechanizm enkapsulacji klucza oparty na sieciach modułowych, standaryzowany jako FIPS 203) z zestawem parametrów 768, wraz z krzywą eliptyczną Diffie-Hellman X25519, a następnie łączy oba wyniki w klucz sesji.

W przypadku starszego serwera można zobaczyć zamiast tego:

debug1: kex: algorithm: curve25519-sha256

Ta nazwa nie posiada części postkwantowej. curve25519-sha256 to samodzielna krzywa eliptyczna Diffie-Hellman, którą duży komputer kwantowy jest w stanie złamać. To właśnie powód, dla którego zmieniono ustawienie domyślne.

Jedna zasada negocjacji wyjaśnia, dlaczego pojedyncza stara maszyna ogranicza sesję. Klient wysyła swoją listę w kolejności preferencji, serwer wysyła własną, a wybrany algorytm to pierwsza nazwa z listy klienta, która pojawia się również na liście serwera. Preferencja klienta wygrywa, więc to starszy z dwóch końców decyduje o tym, jak wysoko na liście uda się dotrzeć. Aktualizacja laptopa nie podniesie sesji do serwera, który nigdy nie słyszał o ML-KEM.

Pomiń grep, a ssh -v pokaże resztę negocjacji, w tym linię, której dotyczy następna sekcja:

debug1: kex: host key algorithm: ssh-ed25519

Które wydanie OpenSSH wprowadziło wymianę hybrydową jako domyślną

Informacje o wydaniach (release notes) dostarczają jasnej chronologii. Daty są istotniejsze niż numery wersji, ponieważ wskazują, jak długo rozwiązanie to funkcjonuje w środowisku produkcyjnym.

• 8.5, wydane 2021-03-03, dodało sntrup761x25519-sha512@openssh.com i pozostawiło tę funkcję domyślnie wyłączoną.
• 9.0, wydane 2022-04-08, włączyło ją. Informacje o wydaniu wskazują, że OpenSSH będzie „domyślnie używać hybrydowej metody wymiany kluczy Streamlined NTRU Prime + x25519”. Jest to wydanie, w którym postkwantowa wymiana kluczy stała się standardem.
• 9.9, wydane 2024-09-19, dodało mlkem768x25519-sha256 jako drugą opcję. To samo wydanie nadało starszej metodzie jej zarejestrowaną w IANA nazwę, sntrup761x25519-sha512, dzięki czemu nowsze kompilacje wymieniają ją pod obiema nazwami.
• 10.0, wydane 2025-04-09, uczyniło mlkem768x25519-sha256 domyślnym mechanizmem uzgadniania kluczy.
• 10.1, wydane 2025-10-06, dodało ostrzeżenie klienta w przypadku, gdy połączenie negocjuje wymianę kluczy bez komponentu postkwantowego. Jest to kontrolowane przez opcję WarnWeakCrypto w pliku ssh_config i jest domyślnie włączone.

Kwiecień 2022 roku to data, którą warto zapamiętać. Każda para maszyn z uruchomionym OpenSSH 9.0 lub nowszym wykonuje postkwantową wymianę kluczy od tego czasu, bez konieczności zmiany konfiguracji i bez powiadamiania użytkownika wpisującego ssh.

Które wydanie Ubuntu zawiera to oprogramowanie

Ubuntu zamraża wersję OpenSSH w momencie wydania, a następnie przenosi poprawki bezpieczeństwa do starszych wersji bez zmiany numeru wersji. Dlatego to używane wydanie Ubuntu decyduje o domyślnym algorytmie. Należy sprawdzić maszynę za pomocą ssh -V, zamiast polegać na liście. Według stanu na sierpień 2026 r. repozytorium zawiera następujące wersje:

• 22.04 LTS zawiera 1:8.9p1, która jest starsza niż wersja 9.0, więc standardowa instalacja negocjuje curve25519-sha256.
• 24.04 LTS zawiera 1:9.6p1, która jest nowsza niż 9.0 i starsza niż 9.9, więc jej domyślnym ustawieniem jest sntrup761x25519-sha512@openssh.com i nie posiada ona ML-KEM.
• 25.10 zawiera 1:10.0p1, której wartością domyślną jest mlkem768x25519-sha256.
• 26.04 LTS zawiera 1:10.2p1, która domyślnie używa mlkem768x25519-sha256 i ostrzega o połączeniach, które nie są postkwantowe.

Należy przeprowadzić test na rzeczywistej parze maszyn. Laptop z 26.04 łączy się z serwerem 24.04. Pierwszy wybór klienta, mlkem768x25519-sha256, nie znajduje się na liście serwera 9.6. Kolejnym postkwantowym wyborem klienta, który serwer posiada, jest sntrup761x25519-sha512@openssh.com i to właśnie tę nazwę raportuje ssh -v. Sesja wykorzystuje wymianę kluczy postkwantowych z serwerem zbudowanym w 2024 r., bez żadnej dodatkowej konfiguracji.

W przypadku 22.04 sytuacja wygląda odwrotnie i pokazuje dokładnie, dlaczego samo ssh -Q kex wprowadza w błąd. OpenSSH 8.9 rozpoznaje nazwę sntrup761x25519-sha512@openssh.com, więc ssh -Q kex na tej maszynie wyświetla ją na liście, ale domyślna propozycja ją pomija, więc negocjacja kończy się na curve25519-sha256. W przypadku klienta OpenSSH 10.1 lub nowszego, połączenie zwraca następujący komunikat:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

To ostrzeżenie dotyczy serwera, z którym nawiązywane jest połączenie, a nie klienta. Rozwiązaniem jest aktualizacja serwera. Ustawienie WarnWeakCrypto no usuwa komunikat, ale nie zmienia niczego w samym połączeniu.

Dlaczego podejście hybrydowe i co oznacza strategia harvest now, decrypt later

Zagrożenie ma konkretną postać. Atakujący, który ma wgląd w ruch sieciowy, rejestruje zaszyfrowane bajty i przechowuje je. Obecnie nie jest w stanie ich odczytać. Przechowuje je do momentu powstania komputera kwantowego o mocy wystarczającej do złamania X25519, a następnie odczytuje ich treść. Zjawisko to nazywa się harvest now, decrypt later lub store now, decrypt later. Nie wymaga ono od atakującego żadnych zaawansowanych działań w teraźniejszości. Wymaga jedynie miejsca na dysku i cierpliwości.

Szyfrowanie posiada ten problem, podczas gdy podpisy cyfrowe nie, a ta asymetria determinuje wszystkie pozostałe aspekty. Zarejestrowany szyfrogram zachowuje swoją wartość tak długo, jak długo zawarte w nim dane pozostają poufne. Podpis musi być niemożliwy do podrobienia jedynie w momencie jego weryfikacji. Złamanie algorytmu podpisu w 2035 roku pozwoli komuś podszyć się pod serwer w 2035 roku. Nie pozwoli jednak na powrót do przeszłości i sfałszowanie logowania z 2026 roku. Dlatego wymiana kluczy musiała zostać zabezpieczona w pierwszej kolejności, a kwestia podpisów może poczekać.

Podejście hybrydowe oznacza, że oba algorytmy działają jednocześnie, a wyniki obu zasilają klucz sesji. Aby odzyskać sekret chroniony przez mlkem768x25519-sha256, atakujący musi złamać zarówno ML-KEM 768, jak i X25519. To połączenie jest celowe: ML-KEM jest znacznie nowszy niż X25519 i był poddawany analizie kryptoanalitycznej przez znacznie krótszy czas, więc ewentualna luka znaleziona w nowym algorytmie nie pozbawia użytkownika ochrony, którą już posiadał.

Co jest chronione, a co nie

Wymiana kluczy jest chroniona. Wspólny sekret szyfrujący sesję pochodzi z wymiany hybrydowej, więc nagranie tej sesji wykonane dzisiaj nie stanie się możliwe do odczytania po pojawieniu się komputerów kwantowych.

Klucz hosta nie jest chroniony. Linia debug1: kex: host key algorithm: ssh-ed25519 wskazuje na klasyczny podpis, podobnie jak rsa-sha2-512 oraz typy ECDSA (elliptic curve digital signature algorithm). Atakujący dysponujący działającym komputerem kwantowym mógłby sfałszować ten podpis i podszyć się pod serwer, ale tylko podczas aktywnego połączenia w przyszłości, nigdy w odniesieniu do ruchu zarejestrowanego obecnie.

Klucz logowania również nie jest chroniony. Klucz w ~/.ssh/id_ed25519 to ten sam rodzaj klasycznego podpisu i dotyczy go to samo rozumowanie. To, co chroni ten klucz w bieżącym roku, to miejsce jego przechowywania oraz uprawnienia dostępu, dlatego rozsądne zarządzanie kluczami SSH przenosi rzeczywiste ryzyko znacznie dalej niż jakakolwiek nazwa algorytmu na tej stronie.

Nie ma żadnych działań, które można podjąć w obu tych przypadkach, ponieważ nie ma na co przejść. OpenSSH zapowiedziało, że obsługa podpisów postkwantowych pojawi się w przyszłym wydaniu. Dopóki nie zostanie ono udostępnione, OpenSSH nie posiada typu klucza hosta ani typu klucza użytkownika odpornego na ataki kwantowe, a ssh-keygen nie oferuje żadnego z nich. Poradnik zalecający wygenerowanie takiego klucza opisuje oprogramowanie, które jeszcze nie istnieje.

TLS na tym samym serwerze to osobna kwestia z osobną odpowiedzią. TLS (transport layer security) to protokół, którego serwer WWW używa na porcie 443; jest to inna baza kodu z innym harmonogramem aktualizacji. Aktualizacja OpenSSH nie zmienia w tym zakresie niczego. Jeśli używasz certyfikatu z podpisem własnym dla prywatnej usługi na tym samym VPS, jego podpis oraz wymiana kluczy zależą od OpenSSL i serwera WWW, więc należy analizować ten stos technologiczny niezależnie.

Jak postępuje rozsądny administrator

Należy utrzymywać OpenSSH w aktualnej wersji i na tym poprzestać. To cała strategia w tym zakresie. sudo apt update && sudo apt upgrade zapewnia korzystanie z wersji dostarczanej przez wydanie Ubuntu, a przejście na nowszą wersję systemu operacyjnego aktualizuje OpenSSH. Włączenie automatycznych aktualizacji bezpieczeństwa sprawia, że poprawki są instalowane bez konieczności pamiętania o nich. Kompilacja OpenSSH ze źródeł w celu zmiany nazw algorytmów jest nieopłacalna, ponieważ rezygnuje się wtedy z aktualizacji bezpieczeństwa dostarczanych przez dystrybucję dla najbardziej narażonej usługi na serwerze. Jeśli mimo to pobierasz kod źródłowy, sprawdź sumę kontrolną pobranego pliku przed rozpoczęciem budowania.

Nie należy ręcznie wpisywać linii KexAlgorithms. Jest to działanie, które niemal zawsze pogarsza sytuację. Poradnik dotyczący zabezpieczeń z 2018 roku zawiera listę, która była poprawna w 2018 roku, a wklejenie jej do sshd_config zastępuje domyślną listę, zamiast ją uzupełniać. Każdy algorytm opracowany od tego czasu zostaje wykluczony, więc serwer, który negocjowałby mlkem768x25519-sha256 samodzielnie, po cichu przechodzi na to, co pozostało w sztywnej liście. Uruchom sudo sshd -T | grep -i '^kexalgorithms' na każdym przejętym serwerze. Jeśli ta linia jest krótsza niż w świeżej instalacji tego samego wydania, oznacza to, że ktoś ją ograniczył.

Jeśli istnieje uzasadniony powód zmiany listy, należy ją uzupełnić, zamiast zastępować. OpenSSH interpretuje wiodący znak + jako dodanie, wiodący - jako usunięcie, a wiodący ^ jako przeniesienie na początek.

KexAlgorithms ^mlkem768x25519-sha256

Przetestuj plik przed jego użyciem. sudo sshd -t analizuje konfigurację i nie wyświetla niczego, jeśli jest ona poprawna. Linia KexAlgorithms wskazująca algorytm, którego kompilacja nie obsługuje, uniemożliwi start sshd, co na zdalnym serwerze oznacza utratę dostępu. Dlatego podczas pracy należy utrzymywać otwartą drugą sesję. Gdy listy po obu stronach przestają się pokrywać, klient informuje o tym wprost:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Marketingowe hasło „odporny na komputery kwantowe” należy rozumieć jako twierdzenie dotyczące jednej warstwy. Dostawca nazywający produkt odpornym na komputery kwantowe odnosi się do konkretnej warstwy, zazwyczaj wymiany kluczy. Należy pytać o nazwę algorytmu i protokół, którego dotyczy. W przypadku OpenSSH w sierpniu 2026 roku uczciwe stwierdzenie brzmi: wymiana kluczy jest hybrydowa i postkwantowa, podczas gdy podpisy pozostają klasyczne. Każde szersze twierdzenie powinno zawierać nazwę, którą można znaleźć w wyniku polecenia ssh -Q kex.

Należy kontynuować rutynowe czynności. Postkwantowa wymiana kluczy nie chroni przed łatwym do odgadnięcia hasłem ani przed kluczem prywatnym skopiowanym na laptopa, który zostanie skradziony. To właśnie takie czynniki najczęściej prowadzą do przejęcia serwerów, a standardowe zabezpieczanie SSH na VPS nadal stanowi najważniejszy element ochrony. Jeśli etapy negocjacji opisane tutaj były niejasne, opis działania SSH podczas nawiązywania połączenia wyjaśnia etapy, które ta strona uznaje za znane.

FAQ

Czy moje połączenie SSH jest już postkwantowe?

Uruchom ssh -v yourserver 2>&1 | grep 'kex: algorithm' i odczytaj nazwę, którą wyświetli. mlkem768x25519-sha256 oraz sntrup761x25519-sha512@openssh.com to hybrydowe wymiany postkwantowe. curve25519-sha256, ecdh-sha2-nistp256 oraz każda nazwa diffie-hellman-group są klasyczne. Obie strony muszą posiadać wersję oferującą nazwę postkwantową, ponieważ negocjacja wybiera pierwszy wybór klienta obsługiwany również przez serwer, więc starsza maszyna wyznacza górny limit.

Które wydanie OpenSSH wprowadziło postkwantową wymianę kluczy jako domyślną?

OpenSSH 9.0, wydane 2022-04-08, uczyniło sntrup761x25519-sha512@openssh.com domyślną wymianą kluczy. OpenSSH 9.9, wydane 2024-09-19, dodało mlkem768x25519-sha256, a OpenSSH 10.0, wydane 2025-04-09, uczyniło tę metodę domyślną. OpenSSH 10.1, wydane 2025-10-06, zaczęło wyświetlać ostrzeżenie, gdy połączenie nie negocjuje żadnej z nich. Sprawdź działanie własnej kompilacji za pomocą ssh -Q kex oraz ssh -G <host>, ponieważ wydanie Ubuntu decyduje o dostępności tych opcji.

Czy powinienem wygenerować postkwantowy klucz SSH?

Nie, ponieważ OpenSSH nie posiada takiego typu klucza. Prace nad odpornością postkwantową obejmują obecnie wymianę kluczy, która nie wymaga od użytkownika plików kluczy ani żadnej konfiguracji. Klucze hosta oraz klucze logowania nadal opierają się na klasycznych podpisach, takich jak Ed25519 czy RSA, a twórcy zapowiedzieli wprowadzenie podpisów postkwantowych w przyszłych wydaniach. Należy nadal używać klucza Ed25519 i dbać o bezpieczeństwo miejsca jego przechowywania.

Dlaczego ssh ostrzega, że moje połączenie nie jest postkwantowe?

OpenSSH 10.1 i nowsze wyświetlają ** WARNING: connection is not using a post-quantum key exchange algorithm., gdy wynegocjowana wymiana nie posiada części postkwantowej. Ostrzeżenie dotyczy serwera, a nie klienta, ponieważ klient zaoferował nazwę postkwantową, której serwer nie zaakceptował. Należy zaktualizować OpenSSH na serwerze lub sprawdzić, czy w pliku sshd_config nie przypięto linii KexAlgorithms, która wyklucza nowoczesne nazwy. Ustawienie WarnWeakCrypto no ukrywa komunikat, pozostawiając połączenie na dotychczasowym poziomie bezpieczeństwa.