OpenSSH 10.4/10.4p1 вышел 6 июля 2026 года и принёс набор исправлений безопасности для sshd, scp, sftp и SSH-клиента. Релиз направлен на усиление безопасности обмена ключами, устранение спорных сценариев при передаче файлов и внедрение экспериментальной поддержки постквантовой подписи ML-DSA 44 с использованием Ed25519.
OpenSSH 10.4 закрывает несколько сценариев с риском обхода ограничений и отказа в обслуживании
Проект OpenSSH опубликовал версию 10.4 и переносимую сборку 10.4p1 в официальных release notes. OpenSSH — это набор программ для защищённого удалённого доступа по протоколу SSH: через него администраторы подключаются к серверам, передают файлы, настраивают туннели и обслуживают инфраструктуру.
В релизе есть отдельный блок security fixes. Исправления затрагивают сразу несколько компонентов: сервер sshd, клиент ssh, scp и sftp. Для пользователей SSH это выглядит как обычное обновление пакета в системе. Администраторам же это дает возможность проверить совместимость конфигураций и запланировать обновления на серверах с открытым SSH.
Самый заметный блок связан с передачей файлов. В sftp исправлен сценарий, при котором вредоносный сервер мог заставить клиента скачать файл в неожиданное место при команде вида sftp host:/path .. В scp исправлена проблема при копировании между двумя удалёнными узлами: вредоносный сервер больше не должен получать возможность записать файл в родительскую директорию относительно ожидаемой целевой папки.
Отдельно разработчики исправили поведение internal-sftp. Это встроенная реализация SFTP-сервера внутри sshd, которую часто используют для ограниченного доступа к файлам без полноценной оболочки. До исправления длинные командные строки могли молча обрезаться после девятого аргумента. Если важная для безопасности опция находилась дальше, она терялась, а администратор мог получить поведение, отличающееся от задуманного.
Более строгий rekey снижает риск накопления лишних данных в памяти
OpenSSH 10.4 ужесточает транспортный протокол во время повторного обмена ключами после аутентификации. Повторный обмен ключами, или rekey, нужен для обновления криптографического материала в уже установленном SSH-сеансе. Это штатная часть долгих соединений: например, когда администратор держит постоянную сессию на сервере или передаёт большой объём данных.
В прежнем поведении вредоносная сторона могла продолжать отправлять сообщения, которые не относятся к обмену ключами. Такие сообщения буферизовались, из-за чего клиент или сервер расходовал память до завершения соединения либо до достижения лимита. В OpenSSH 10.4 такая ситуация приводит к разрыву соединения.
OpenSSH становится строже к реализации протокола у другой стороны. Совместимые клиенты и серверы продолжат работать штатно, а реализации, которые допускают лишние сообщения во время key exchange, могут столкнуться с отключением. Для инфраструктуры с нестандартными SSH-шлюзами, устаревшими библиотеками или встроенными устройствами это самый важный пункт для предварительной проверки.
В Linux-сборках сбой seccomp sandbox теперь останавливает sshd
Ещё одно потенциально несовместимое изменение касается Linux-систем с включённой seccomp-песочницей. Seccomp ограничивает набор системных вызовов, доступных процессу, и помогает уменьшить ущерб при эксплуатации уязвимости. В OpenSSH 10.4 сбой включения SECCOMP или NO_NEW_PRIVS теперь считается фатальным для sshd.
Раньше sshd мог записать ошибку в лог и продолжить работу. Такой подход помогал системам без нужной поддержки ядра или окружения, но создавал менее очевидное состояние: администратор мог считать песочницу активной, хотя фактически она не была включена.
Теперь поведение стало жёстче. Если система не поддерживает нужные механизмы, проект указывает на вариант с отключением sandbox на этапе сборки. Для обычных дистрибутивов Linux это обычно решается сопровождающими пакетов, а администраторам самосборок стоит проверить тестовый запуск sshd до развёртывания обновления в production.
sshd -G меняет формат вывода директив конфигурации
OpenSSH 10.4 меняет поведение режима sshd -G, который выводит итоговую конфигурацию сервера после применения настроек. Теперь директивы печатаются в смешанном регистре, например PubkeyAuthentication, тогда как раньше вывод был в нижнем регистре.
На работу самого SSH-сервера это не влияет, но может затронуть скрипты аудита и проверки конфигурации. Если автоматизация ищет конкретные строки в выводе sshd -G, ей может понадобиться корректировка. Особенно это касается простых shell-скриптов, CI-проверок и внутренних compliance-инструментов, где сравнение строк сделано без учёта регистра.
Экспериментальная подпись ML-DSA 44 с Ed25519 готовит OpenSSH к постквантовой криптографии
В OpenSSH 10.4 появилась экспериментальная поддержка составной постквантовой схемы подписи, объединяющей ML-DSA 44 и Ed25519. ML-DSA относится к классу алгоритмов цифровой подписи, рассчитанных на устойчивость к будущим квантовым атакам. Ed25519 остаётся привычной современной схемой, широко используемой в SSH-ключах.
Схема не включена по умолчанию. Для использования её нужно явно добавить в параметры вроде HostKeyAlgorithms и PubkeyAcceptedAlgorithms, а ключ можно создать командой ssh-keygen -t mldsa44-ed25519.
Для большинства серверов этот материал пока подходит только для тестовых стендов и начальной оценки совместимости. Главные нововведения — возможность заранее посмотреть, как постквантовые подписи будут вести себя в реальных SSH-сценариях: при выпуске ключей, настройке политик допуска, проверке клиентов и работе с автоматизацией.
Исправления в ssh-agent, FIDO-ключах и sftp закрывают менее заметные сбои
В релизе, помимо значительных изменений, представлен длинный перечень улучшений для повседневных инструментов. В ssh-agent исправлен ответ на запросы расширения query, а также добавлены ограничения, чтобы слишком длинные имена пользователей в constraints не приводили к отказу в обслуживании.
В связке ssh-keygen и ssh-add улучшена работа с FIDO-токенами: при загрузке resident keys теперь пропускаются неподдерживаемые типы ключей, вместо остановки всей операции. Это важно для пользователей аппаратных ключей, где на одном устройстве могут храниться разные типы учётных данных.
В sftp исправлены чтения за пределами буфера на один байт, проблемы с REALPATH, утечки файловых дескрипторов в дочерние процессы и сценарий, при котором загрузка могла застрять в цикле при некорректном ответе сервера. Эти исправления обычно незаметны после обновления, но они уменьшают число странных отказов и пограничных ошибок в автоматизированных передачах файлов.
Администраторам рекомендуется провести проверку нестандартных клиентов
OpenSSH 10.4 — важный релиз для серверной инфраструктуры, использующей SSH, SFTP и автоматизацию через scp/sftp. В типичной Linux-системе обновление появится через пакеты дистрибутива, а детали сборки, включая seccomp-sandbox, будут решать сопровождающие.
Зоны, где полезна ручная проверка, уже понятны: нестандартные SSH-реализации, долгие соединения с rekey, самосборки sshd на Linux, скрипты вокруг sshd -G, внутренние SFTP-профили на базе internal-sftp и тестовые эксперименты с новыми типами ключей.
Для производственных серверов оптимальный подход остаётся консервативным: сначала обновить тестовый сервер, затем проверить аутентификацию по ключам, доступ через SFTP, туннели, сценарии jump-host и внутренние настройки конфигурации. Только после этого можно распространять обновление на остальные серверы, избегая неожиданных проблем с доступом через SSH.
