Постквантовый 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 гибридный обмен ключами стал стандартным

В примечаниях к выпуску от разработчиков приведена четкая последовательность. Даты важнее номеров версий, так как они показывают, как долго эта функция работает в фоновом режиме.

• 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 на момент релиза, а затем переносит в неё исправления безопасности (backport), не меняя номер версии. Поэтому используемый вами релиз 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 скроет сообщение, но уровень безопасности соединения останется прежним.