Постквантовий 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 разом із протоколом обміну ключами Diffie-Hellman на еліптичній кривій X25519, а потім об’єднує обидва результати в ключ сеансу.

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

debug1: kex: algorithm: curve25519-sha256

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

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

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

debug1: kex: host key algorithm: ssh-ed25519

Який випуск OpenSSH зробив гібридний обмін типовим

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

• 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 прибирає повідомлення, але не змінює параметри з’єднання.

Чому гібридний режим і що означає «зібрати зараз, розшифрувати пізніше»

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

Ця проблема стосується шифрування, але не підписів, і саме ця асиметрія визначає все інше. Записаний шифротекст зберігає цінність доти, доки дані всередині нього залишаються конфіденційними. Підпис має бути невідтворюваним лише в момент перевірки. Якщо у 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 вручну. Це єдина дія, яка гарантовано погіршує ситуацію. Посібник із посилення безпеки за 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, описує певний названий ним рівень, і зазвичай це рівень обміну ключами. Запитайте назву алгоритму та протокол, до якого він застосовується. Для OpenSSH у серпні 2026 року коректне формулювання таке: обмін ключами є гібридним постквантовим, а підписи залишаються класичними. Ширше твердження має супроводжуватися назвою, яку можна знайти у виведенні ssh -Q kex.

Продовжуйте виконувати звичайні базові заходи. Постквантовий обмін ключами нічого не змінює для пароля, який легко вгадати, або приватного ключа, скопійованого на ноутбук, який згодом викрали. Саме через такі проблеми сервери фактично зламують, а стандартне посилення безпеки 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. Розробники upstream повідомили, що постквантові підписи з’являться в майбутньому релізі. Продовжуйте використовувати ключ Ed25519 і захищайте місце його зберігання.

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

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