Постквантовий SSH: що змінилося в Ubuntu

Що змінилося в постквантовому SSH

Постквантовий SSH уже ввімкнено для більшості користувачів, і нікому не потрібно було налаштовувати його вручну. Сучасний клієнт OpenSSH, підключаючись до сучасного сервера OpenSSH, за замовчуванням вибирає гібридний постквантовий обмін ключами. Тому ключ сеансу залишається стійким до атак, за яких зловмисник записує ваш мережевий трафік сьогодні, а через роки розшифровує його. Захист є реальним, але він вужчий, ніж може припускати вислів «квантово-безпечний SSH».

Спочатку розглянемо два терміни. SSH (secure shell) — це протокол, за допомогою якого ви входите на сервер. Обмін ключами, який зазвичай позначають як «kex», є першим етапом кожного SSH-з’єднання: обидві сторони узгоджують спільний секрет, а цей секрет шифрує все, що передається далі. Змінилася саме процедура обміну ключами. Більше нічого.

Не довіряйте цій сторінці, виконайте команди

Назви всіх алгоритмів нижче отримано з команд, які ви можете виконати самостійно. Це зроблено навмисно. Набір алгоритмів за замовчуванням змінюється з кожним випуском OpenSSH, тому посібник, написаний два роки тому, може містити назву алгоритму, якому ваша машина більше не надає перевагу, і не повідомить вам про це. Вивчіть ці команди, і вам більше не знадобляться статті на цю тему, зокрема ця.

Почніть із перевірки можливостей вашої збірки.

ssh -V
ssh -Q kex

Команда ssh -V виводить рядок із версією, що починається з OpenSSH_, а потім суфікс пакета Ubuntu і версію OpenSSL. Команда ssh -Q kex виводить по одному алгоритму обміну ключами в кожному рядку. У збірці з підтримкою постквантових алгоритмів у цьому списку будуть такі назви, як mlkem768x25519-sha256 і sntrup761x25519-sha512@openssh.com, поруч із класичними назвами на зразок curve25519-sha256.

Підтримка вашої збірки — це не те саме, що вона пропонує

Це розрізнення пропускає більшість публікацій. ssh -Q kex відповідає на одне запитання: що цей бінарний файл може робити. Але це не відповідає на важливіше для вас запитання: що саме це з’єднання фактично запропонує. Ці два списки відрізняються, і саме через цю різницю старі рекомендації завдають реальної шкоди.

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

ssh -G <host> виводить фактичну конфігурацію клієнта для цього хоста після застосування ~/.ssh/config і /etc/ssh/ssh_config. sshd -T робить те саме для сервера. Кожна команда виводить один рядок kexalgorithms у порядку пріоритету, і перша назва в ньому є першим вибором відповідної сторони. Саме цей рядок передається через мережу.

Ця різниця не є теоретичною. OpenSSH 8.5, випущений 2021-03-03, додав sntrup761x25519-sha512@openssh.com і навмисно не включив його до списку за замовчуванням. У цій версії ssh -Q kex показує алгоритм, а ssh -G — ні. Це означає, що бінарний файл підтримує постквантовий обмін ключами, але жодне з’єднання не пропонує його.

Прочитайте алгоритм, узгоджений вашим з’єднанням

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

Для сучасних клієнта та сервера команда виведе:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 — гібридний алгоритм. Він використовує ML-KEM (механізм інкапсуляції ключа на основі модуло-ґратки, стандартизований як FIPS 203) із набором параметрів 768 разом із протоколом обміну ключами Діффі—Геллмана на еліптичній кривій X25519, а потім об’єднує обидва результати в ключ сеансу.

Під час підключення до старішого сервера замість цього може відображатися:

debug1: kex: algorithm: curve25519-sha256

У цій назві немає постквантової складової. curve25519-sha256 — це самостійний обмін ключами Діффі—Геллмана на еліптичній кривій, який можна зламати за допомогою потужного квантового комп’ютера. Саме тому алгоритм за замовчуванням було змінено.

Одне правило узгодження пояснює, чому один старий комп’ютер обмежує сеанс. Клієнт надсилає свій список у порядку пріоритету, сервер надсилає власний список, а алгоритмом стає перша назва зі списку клієнта, яка також є у списку сервера. Пріоритет має клієнт, тому саме старіша з двох сторін визначає, наскільки високо у списку можна піднятися. Оновлення ноутбука не оновлює сеанс із сервером, який ніколи не підтримував ML-KEM.

ssh -v варто знати не лише для цього рядка, оскільки той самий вивід допомагає виявити причину помилки Permission denied (publickey), коли вхід повністю відхилено.

Видаліть grep, і ssh -v покаже решту узгодження, зокрема рядок, якому присвячено наступний розділ:

debug1: kex: host key algorithm: ssh-ed25519

Який реліз OpenSSH зробив гібридний обмін ключами стандартним

Примітки до релізів upstream дають чітку послідовність. Дати важливіші за номери версій, оскільки показують, як довго це непомітно працює.

• 8.5, випущений 2021-03-03, додав sntrup761x25519-sha512@openssh.com і залишив його вимкненим за замовчуванням.
• 9.0, випущений 2022-04-08, увімкнув його. У примітках зазначено, що OpenSSH «за замовчуванням використовуватиме гібридний метод обміну ключами Streamlined NTRU Prime + x25519». Саме в цьому релізі обмін ключами з постквантовим компонентом став стандартним варіантом.
• 9.9, випущений 2024-09-19, додав mlkem768x25519-sha256 як другий варіант. У цьому самому релізі старий метод отримав зареєстровану IANA назву sntrup761x25519-sha512, тому новіші збірки вказують його під обома назвами.
• 10.0, випущений 2025-04-09, зробив mlkem768x25519-sha256 методом обміну ключами за замовчуванням.
• 10.1, випущений 2025-10-06, додав попередження клієнта, коли під час встановлення з’єднання узгоджується метод обміну ключами без постквантової складової. Цим керує параметр WarnWeakCrypto у ssh_config; за замовчуванням він увімкнений.

Варто запам’ятати дату — квітень 2022 року. Будь-яка пара машин під керуванням OpenSSH 9.0 або новішої версії відтоді виконує постквантовий обмін ключами без додаткової конфігурації та без повідомлення користувача, який вводить ssh.

Який реліз Ubuntu постачає цю версію

Ubuntu фіксує версію OpenSSH під час випуску релізу, а потім переносить до неї виправлення безпеки, не змінюючи номер версії. Тому версія Ubuntu визначає алгоритм за замовчуванням. Перевірте потрібну машину за допомогою ssh -V, а не покладайтеся на список. Станом на August 2026 в архіві доступні такі версії:

• 22.04 LTS постачається з 1:8.9p1. Ця версія старіша за 9.0, тому стандартне встановлення узгоджує curve25519-sha256.
• 24.04 LTS постачається з 1:9.6p1. Ця версія новіша за 9.0, але старіша за 9.9, тому алгоритм за замовчуванням — sntrup761x25519-sha512@openssh.com, а ML-KEM відсутній.
• 25.10 постачається з 1:10.0p1, версія якого використовує mlkem768x25519-sha256 за замовчуванням.
• 26.04 LTS постачається з 1:10.2p1. Ця версія використовує mlkem768x25519-sha256 за замовчуванням і попереджає про з’єднання, які не використовують постквантову криптографію.

Розглянемо реальну пару машин. Ноутбук із 26.04 підключається до сервера з 24.04. Перший вибір клієнта, mlkem768x25519-sha256, відсутній у списку сервера з версією 9.6. Наступний постквантовий варіант клієнта, який підтримує сервер, — sntrup761x25519-sha512@openssh.com. Саме це ім’я показує ssh -v. Обмін ключами в сеансі є постквантовим, хоча сервер зібрано у 2024 році, і ніхто нічого не налаштовував.

Випадок із 22.04 працює навпаки та точно показує, чому ssh -Q kex без додаткового контексту вводить в оману. OpenSSH 8.9 знає назву sntrup761x25519-sha512@openssh.com, тому ssh -Q kex на цій машині показує її. Але пропозиція за замовчуванням не містить цей алгоритм, тому узгодження завершується вибором curve25519-sha256. Клієнт OpenSSH 10.1 або новішої версії повідомляє про це:

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

Це попередження стосується сервера, до якого ви підключаєтеся, а не вашого клієнта. Рішення — оновити сервер. Встановлення WarnWeakCrypto no прибирає повідомлення, але не змінює з’єднання.

Чому гібридна схема і що означає harvest now, decrypt later

Загроза має просту форму. Зловмисник, який може бачити ваш мережевий трафік, сьогодні записує зашифровані байти та зберігає їх. Сьогодні він не може їх прочитати. Він зберігає їх доти, доки не з’явиться квантовий комп’ютер, достатньо потужний для злому X25519, а потім читає їх. Це називають harvest now, decrypt later або store now, decrypt later. Така атака не потребує від зловмисника складних дій у теперішньому. Потрібні лише дисковий простір і терпіння.

Шифрування має цю проблему, а цифрові підписи — ні, і ця асиметрія визначає все інше. Записаний шифротекст зберігає цінність доти, доки дані всередині нього залишаються конфіденційними. Цифровий підпис має бути непідробним лише в момент перевірки. Злам алгоритму цифрового підпису у 2035 році дасть змогу комусь видати себе за сервер у 2035 році. Це не дасть змоги повернутися в минуле й підробити вхід до системи з 2026 року. Тому спочатку потрібно було захистити обмін ключами, а зі стороною цифрових підписів можна зачекати.

Гібридна схема означає, що обидва алгоритми виконуються, а обидва результати використовуються для формування ключа сеансу. Щоб відновити секрет, що стоїть за mlkem768x25519-sha256, зловмисник має зламати ML-KEM 768 і X25519. Таке поєднання є навмисним: ML-KEM набагато новіший за X25519 і мав значно менше часу під атакою криптоаналітиків, тому вразливість, виявлена в новому алгоритмі, не позбавить вас захисту, який уже надавався.

Що захищено, а що — ні

Обмін ключами захищений. Спільний секрет, яким шифрується ваш сеанс, отримано в результаті гібридного обміну, тому запис цього сеансу, зроблений сьогодні, не стане доступним для читання після появи квантових комп’ютерів.

Ключ хоста не захищений. Рядок debug1: kex: host key algorithm: ssh-ed25519 задає класичний цифровий підпис. Те саме стосується rsa-sha2-512 і типів ECDSA (алгоритм цифрового підпису на еліптичних кривих). Зловмисник із працездатним квантовим комп’ютером зможе підробити цей підпис і видати себе за ваш сервер, але лише під час активного з’єднання в майбутньому. На трафік, записаний зараз, це не вплине.

Ваш ключ для входу також не захищений. Ключ у ~/.ssh/id_ed25519 є таким самим класичним цифровим підписом, тому тут діє те саме пояснення. Цього року цей ключ захищають місце його зберігання та права доступу до нього. Тому належне керування SSH-ключами значно важливіше для вашого реального рівня ризику, ніж назва будь-якого алгоритму на цій сторінці.

Вам не потрібно нічого робити щодо жодного з цих ключів, оскільки наразі немає альтернативи, на яку можна перейти. OpenSSH повідомляє, що підтримка постквантових цифрових підписів з’явиться в майбутньому релізі. Поки цей реліз не випущено, OpenSSH не має постквантового типу ключа хоста та постквантового типу ключа користувача, а ssh-keygen не пропонує жодного з них. Інструкція, яка радить згенерувати такий ключ, описує програмне забезпечення, якого ще не існує.

TLS на тому самому сервері — окреме питання з окремою відповіддю. TLS (безпека транспортного рівня) — це протокол, який ваш вебсервер використовує на порту 443. Це інша кодова база з окремим графіком оновлень. Оновлення OpenSSH нічого там не змінює. Якщо ви використовуєте самопідписаний сертифікат для приватного сервісу на тому самому VPS, його підпис і обмін ключами визначаються OpenSSL та вашим вебсервером. Тому оцінюйте цей стек окремо.

Що в такій ситуації робить розсудливий адміністратор

Підтримуйте OpenSSH в актуальному стані — і на цьому зупиніться. Для цієї проблеми це справді вся стратегія. sudo apt update && sudo apt upgrade залишає вас на версії, яку постачає ваш реліз Ubuntu, а перехід на новіший реліз Ubuntu оновлює OpenSSH до новішої версії. Увімкнення автоматичного встановлення оновлень безпеки дає змогу застосовувати ці виправлення без ручного контролю. Збірка OpenSSH із вихідного коду заради певної назви алгоритму — невигідний компроміс, оскільки ви втрачаєте оновлення безпеки дистрибутива для найбільш відкритого сервісу на сервері. Якщо ви все ж завантажуєте вихідний код, перевірте завантажений файл за опублікованою контрольною сумою перед збіркою.

Не прописуйте рядок KexAlgorithms вручну. Це єдина дія, яка гарантовано погіршує ситуацію. Посібник із hardening, написаний у 2018 році, містить список, правильний для 2018 року, а вставлення цього списку в sshd_config замінює список за замовчуванням, а не доповнює його. Усі алгоритми, створені відтоді, тепер виключені, тому сервер, який самостійно узгодив би mlkem768x25519-sha256, непомітно переходить до того, що залишилося в зафіксованому списку. Виконайте sudo sshd -T | grep -i '^kexalgorithms' на будь-якому успадкованому сервері. Якщо цей рядок коротший за рядок на чистій інсталяції того самого релізу, хтось зафіксував список вручну.

Якщо у вас є реальна причина змінити список, доповнюйте його, а не замінюйте. OpenSSH сприймає початковий + як додавання, початковий - — як видалення, а початковий ^ — як переміщення на початок.

KexAlgorithms ^mlkem768x25519-sha256

Перевірте файл, перш ніж покладатися на нього. sudo sshd -t аналізує конфігурацію і не виводить нічого, якщо вона коректна. Рядок KexAlgorithms із назвою алгоритму, якого немає в цій збірці, не дає sshd запуститися. На віддаленому сервері це означає, що ви не зможете повторно підключитися, тому під час роботи залишайте відкритою другу сесію. Коли списки на двох сторонах більше не мають спільних алгоритмів, клієнт прямо повідомляє про це:

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

Сприймайте маркетингові заяви про «quantum-safe» як твердження лише про один рівень. Постачальник, який називає продукт quantum-safe, описує саме той рівень, який він зазначив, і зазвичай це обмін ключами на певному етапі. Запитайте назву алгоритму та протокол, до якого він застосовується. Для OpenSSH у серпні 2026 року коректне формулювання таке: обмін ключами є гібридним post-quantum, а підписи залишаються класичними. Ширше твердження має супроводжуватися назвою, яку можна знайти у виведенні ssh -Q kex.

Продовжуйте виконувати базові, але важливі дії. Post-quantum обмін ключами не захищає від пароля, який легко вгадати, або приватного ключа, скопійованого на ноутбук, який згодом викрали. Саме через такі проблеми сервери фактично компрометують, а стандартне hardening SSH на VPS і далі забезпечує майже весь необхідний захист. Якщо етапи узгодження, описані тут, були для вас незнайомими, у матеріалі що робить SSH під час підключення описано етапи, які передбачається знати з цієї сторінки.

FAQ

Чи є моє SSH-з’єднання постквантовим?

Виконайте ssh -v yourserver 2>&1 | grep 'kex: algorithm' і прочитайте назву, яку вона виведе. mlkem768x25519-sha256 і sntrup761x25519-sha512@openssh.com — це гібридні постквантові обміни ключами. curve25519-sha256, ecdh-sha2-nistp256 і будь-яка назва diffie-hellman-group є класичними. Обидві сторони мають використовувати версію, яка підтримує постквантову назву, оскільки під час узгодження обирається перший варіант клієнта, який також підтримує сервер. Тому саме старіша машина визначає верхню межу.

У якому випуску OpenSSH постквантовий обмін ключами став типовим?

OpenSSH 9.0, випущений 2022-04-08, зробив sntrup761x25519-sha512@openssh.com типовим обміном ключами. OpenSSH 9.9, випущений 2024-09-19, додав mlkem768x25519-sha256, а OpenSSH 10.0, випущений 2025-04-09, зробив саме його типовим. OpenSSH 10.1, випущений 2025-10-06, почав виводити попередження, якщо під час з’єднання не узгоджено жодного з них. Перевірте поведінку власної збірки за допомогою ssh -Q kex і ssh -G <host>, оскільки саме ваш випуск Ubuntu визначає, які з цих можливостей доступні.

Чи слід мені згенерувати постквантовий SSH-ключ?

Ні, оскільки OpenSSH не має такого типу ключів. Наразі постквантові зміни стосуються обміну ключами. Для нього не потрібні ваші файли ключів або будь-які налаштування. Ключі хостів і ключі для входу досі використовують класичні підписи, наприклад Ed25519 і RSA. Проєкт OpenSSH повідомив, що постквантові підписи з’являться в майбутньому випуску. Продовжуйте використовувати ключ Ed25519 і захищайте місце його зберігання.

Чому ssh попереджає, що моє з’єднання не є постквантовим?

OpenSSH 10.1 і новіші версії виводять ** WARNING: connection is not using a post-quantum key exchange algorithm., якщо узгоджений обмін не має постквантової складової. Попередження стосується сервера, а не вашого клієнта, оскільки клієнт запропонував постквантову назву, але сервер не прийняв жодної з них. Оновіть OpenSSH на сервері або перевірте, чи не зафіксував хтось рядок KexAlgorithms у його sshd_config, виключивши сучасні назви. Встановлення WarnWeakCrypto no приховує повідомлення, але залишає з’єднання таким самим слабким, як і раніше.