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 automatycznie wybiera hybrydową wymianę kluczy postkwantowych. Dzięki temu klucz sesji jest odporny na ataki polegające na rejestrowaniu ruchu sieciowego w celu jego odszyfrowania w przyszłości. Ochrona ta jest rzeczywista, choć jej zakres jest węższy, 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 ustalają wspólny sekret, który służy do szyfrowania całej dalszej komunikacji. Zmiana dotyczy wyłącznie tego etapu. Żadne inne elementy protokołu nie uległy 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 sposobu, aby Cię o tym powiadomić. Naucz się tych poleceń, a przestaniesz potrzebować artykułów na ten temat, w tym tego konkretnego.

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 wypisuje 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, znajdujące się obok klasycznych nazw, takich jak curve25519-sha256.

To, co wspiera kompilacja, nie jest tym, co oferuje

To rozróżnienie, które pomija większość wpisów. ssh -Q kex odpowiada na jedno pytanie: co ten plik binarny potrafi zrobić. Nie odpowiada na pytanie, które jest istotne: co to połączenie faktycznie zaproponuje. Te dwie listy różnią się, a luka między nimi jest miejscem, w którym przestarzałe porady wyrządzają rzeczywiste 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 tym, co trafia do sieci.

Ta luka 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 dla połączenia

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

Pomiędzy aktualnym klientem a aktualnym serwerem wyświetlany jest wynik:

debug1: kex: algorithm: mlkem768x25519-sha256

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

W przypadku starszego serwera można zobaczyć następujący wynik:

debug1: kex: algorithm: curve25519-sha256

Ta nazwa nie zawiera komponentu postkwantowego. curve25519-sha256 to samodzielny algorytm krzywej eliptycznej Diffie-Hellman, który jest podatny na złamanie przez duży komputer kwantowy. To właśnie główny powód zmiany ustawień domyślnych.

Jedna zasada negocjacji wyjaśnia, dlaczego pojedyncza stara maszyna ogranicza jakość sesji. 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 znajduje się również na liście serwera. Preferencja klienta jest nadrzędna, więc to starsze z dwóch urządzeń decyduje o poziomie zabezpieczeń. Aktualizacja laptopa nie podniesie poziomu sesji do serwera, który nie obsługuje ML-KEM.

Warto znać ssh -v nie tylko ze względu na ten jeden wiersz, ponieważ ten sam wynik pozwala zdiagnozować błąd Permission denied (publickey), gdy logowanie jest całkowicie odrzucane.

Usunięcie grep i użycie ssh -v pozwala wyświetlić resztę negocjacji, w tym wiersz, którego 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) dostarczane przez twórców oprogramowania przedstawiają jasną chronologię. 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ą. Zgodnie z informacjami o wydaniu, OpenSSH „używa domyślnie 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 dla 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 wprowadzania zmian w konfiguracji i bez powiadamiania użytkownika wpisującego polecenie ssh.

Które wydanie Ubuntu zawiera daną wersję

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ż domyślna 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 wartością domyślną 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ą odporne na ataki kwantowe.

Przeanalizujmy rzeczywistą parę 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 wyborem klienta odpornym na ataki kwantowe, który serwer posiada, jest sntrup761x25519-sha512@openssh.com i to właśnie tę nazwę zgłasza ssh -v. Sesja jest odporna na ataki kwantowe w zakresie wymiany kluczy, mimo że serwer zbudowano w 2024 r. i nikt nie dokonywał żadnej 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 informuje o tym:

** 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 „przechowuj teraz, odszyfruj później”

Zagrożenie ma prostą 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 dane. Zjawisko to nazywa się „przechowuj teraz, odszyfruj później” (ang. harvest now, decrypt later lub store now, decrypt later). Nie wymaga ono od atakującego zaawansowanych działań w teraźniejszości. Wymaga jedynie miejsca na dysku i cierpliwości.

Szyfrowanie posiada ten problem, natomiast 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ą równolegle, 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. Dzięki temu 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 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. Tym, co chroni ten klucz w bieżącym roku, jest miejsce jego przechowywania oraz uprawnienia dostępu, dlatego rozsądne zarządzanie kluczami SSH przesuwa 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 alternatyw, na które można 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 odrębne zagadnienie z odrębną odpowiedzią. TLS (transport layer security) to protokół używany przez serwer WWW na porcie 443, oparty na innym kodzie źródłowym i rozwijany według innego harmonogramu. 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, dlatego kwestie te należy rozpatrywać w kontekście tego konkretnego stosu technologicznego.

Jak postępuje rozsądny administrator

Należy dbać o aktualność OpenSSH i na tym poprzestać. To w zasadzie cała strategia dla tego problemu. sudo apt update && sudo apt upgrade utrzymuje wersję dostarczaną przez wydanie Ubuntu, a przejście na nowszą wersję systemu operacyjnego zapewnia nowsze OpenSSH. Włączenie automatycznych aktualizacji bezpieczeństwa sprawia, że poprawki są stosowane bez konieczności pamiętania o nich. Kompilacja OpenSSH ze źródeł w celu uzyskania konkretnego algorytmu 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 kompilacji.

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 sam wynegocjowałby mlkem768x25519-sha256, po cichu przechodzi na to, co pozostało na 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 + na początku jako dodanie, - jako usunięcie, a ^ 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 nie obsługuje dana kompilacja, uniemożliwi start sshd. Na zdalnym serwerze oznacza to brak możliwości ponownego zalogowania, 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ła o "odporności na komputery kwantowe" należy traktować jako deklarację dotyczącą jednej warstwy. Dostawca nazywający produkt odpornym kwantowo 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, postkwantowa, podczas gdy podpisy pozostają klasyczne. Każde szersze twierdzenie powinno być poparte 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 te czynniki najczęściej prowadzą do przejęcia serwerów, a standardowe zabezpieczanie SSH na VPS nadal stanowi fundament bezpieczeństwa. Jeśli etapy negocjacji opisane tutaj były niejasne, opis działania SSH podczas nawiązywania połączenia wyjaśnia fazy, których znajomość jest wymagana w tym dokumencie.

FAQ

Czy moje połączenie SSH jest już odporne na ataki kwantowe?

Uruchom ssh -v yourserver 2>&1 | grep 'kex: algorithm' i odczytaj nazwę, która zostanie wyświetlona. mlkem768x25519-sha256 oraz sntrup761x25519-sha512@openssh.com to hybrydowe mechanizmy wymiany kluczy odporne na ataki kwantowe. curve25519-sha256, ecdh-sha2-nistp256 oraz każda nazwa diffie-hellman-group są klasyczne. Obie strony muszą posiadać wersję obsługującą nazwy post-kwantowe, ponieważ negocjacja wybiera pierwszy wybór klienta obsługiwany również przez serwer, co oznacza, że starsza maszyna ogranicza możliwości połączenia.

W której wersji OpenSSH wymiana kluczy post-kwantowa stała się domyślna?

OpenSSH 9.0, wydane 2022-04-08, uczyniło sntrup761x25519-sha512@openssh.com domyślną metodą wymiany 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żenia, gdy połączenie nie negocjuje żadnej z nich. Sprawdź działanie własnej kompilacji za pomocą ssh -Q kex oraz ssh -G <host>, ponieważ dystrybucja Ubuntu decyduje o tym, która z nich jest dostępna.

Czy powinienem wygenerować klucz SSH odporny na ataki kwantowe?

Nie, ponieważ OpenSSH nie posiada takiego typu klucza. Prace nad odpornością na ataki kwantowe obejmują obecnie wymianę kluczy, która nie wymaga od użytkownika plików kluczy ani żadnej konfiguracji. Klucze hosta oraz klucze logowania nadal wykorzystują klasyczne podpisy, takie jak Ed25519 czy RSA, a twórcy oprogramowania zapowiedzieli wprowadzenie podpisów post-kwantowych w przyszłych wydaniach. Nadal używaj klucza Ed25519 i chroń miejsce jego przechowywania.

Dlaczego ssh ostrzega, że moje połączenie nie jest odporne na ataki kwantowe?

OpenSSH 10.1 i nowsze wyświetlają ** WARNING: connection is not using a post-quantum key exchange algorithm., gdy wynegocjowana wymiana nie posiada komponentu post-kwantowego. Ostrzeżenie dotyczy serwera, a nie klienta, ponieważ klient zaproponował nazwę post-kwantową, której serwer nie zaakceptował. Zaktualizuj OpenSSH na serwerze lub sprawdź, czy w pliku sshd_config nie zdefiniowano linii KexAlgorithms, która wyklucza nowoczesne nazwy. Ustawienie WarnWeakCrypto no ukrywa komunikat, pozostawiając połączenie na dotychczasowym poziomie bezpieczeństwa.