Как проверить постквантовый 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, а не полагайтесь на списки. По состоянию на август 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, после чего он их расшифровывает. Это называется «собирай сейчас, расшифровывай потом» (harvest 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 (transport layer security) — это протокол, который использует ваш веб-сервер на 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

Воспринимайте маркетинг «квантовой устойчивости» как заявление об одном уровне защиты. Вендор, называющий продукт квантово-устойчивым, описывает конкретный слой, обычно это обмен ключами. Запрашивайте название алгоритма и протокол, к которому он применяется. Для 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. Разработчики сообщили, что постквантовые подписи появятся в будущих релизах. Продолжайте использовать ключ Ed25519 и обеспечьте безопасность места его хранения.

Почему ssh предупреждает, что мое соединение не является постквантовым?

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