OpenSSH hardening 2026: KEX, hostkey, CA подписи и FIDO2-ключи без боли для легаси

Зачем «hardening» OpenSSH в 2026-м: что реально ломают и что реально ломается

Если у вас SSH — это «просто вход на сервер», то hardening обычно вспоминают после инцидента: украденный ключ, пониженная криптография ради совместимости, неожиданный клиент из CI, который перестал подключаться после апдейта. В 2026 году типичные причины навести порядок в sshd_config такие:

• Снижение поверхности атаки: убрать устаревшие KEX/hostkey/подписи, которые либо уже слабы, либо создают риск downgrade и плохо аудируются.
• Предсказуемая совместимость: заранее зафиксировать «поддерживаемый профиль» и отдельно оформить исключения для legacy клиентов.
• Управляемая аутентификация: FIDO2-ключи (security keys), SSH-сертификаты, ограничения по подписи CA и пользовательским ключам.
• Проверяемость: чтобы вывод sshd -T и аудит показывали короткий набор современных алгоритмов вместо «зоопарка».

Важно: «сделать максимально жёстко» — не цель сама по себе. Цель — свести криптополитику к минимальному набору безопасных алгоритмов и при необходимости точечно оставить совместимость через Match (по пользователю, адресам/подсети или порту).

Базовая методика: инвентаризация, политика, затем изменения

Шаг 1. Узнайте, что у вас реально включено

Начните не с редактирования, а с фактической конфигурации после всех include и дефолтов:

sshd -T

Команда печатает итоговые значения (включая дефолты). Это лучший способ понять, что «на самом деле» применится после перезагрузки.

Шаг 2. Поймите, кто к вам ходит и какими клиентами

Самый практичный источник — логи. На большинстве систем удобно смотреть журнал sshd и вылавливать строки про ошибки согласования алгоритмов. Даже если вы не видите полный набор negotiated параметров, по сообщениям вида «no matching key exchange method found» быстро понятно, где легаси.

Если у вас есть jump/bastion — это отличная точка, чтобы определить минимальный набор совместимости, а на «внутренних» серверах сделать профиль жёстче.

Шаг 3. План отката и безопасное применение

Два правила, которые экономят часы:

• Перед применением всегда проверяйте синтаксис: sshd -t.
• Держите вторую сессию (или out-of-band доступ). Не закрывайте текущий SSH до успешной проверки нового подключения.

Криптопрофиль 2026: что выбирать для KEX и почему

Параметр KexAlgorithms управляет тем, как стороны договариваются о ключах сеанса. В 2026-м «здоровый минимум» обычно строится вокруг curve25519 и (при необходимости) современных DH-групп.

Рекомендованный минимум для современных клиентов

Чаще всего достаточно оставить:

• curve25519-sha256 (и совместимый вариант curve25519-sha256@libssh.org, если встречаются клиенты, которые знают только его)
• diffie-hellman-group16-sha512 как «запасной» вариант для совместимости с рядом корпоративных окружений
• diffie-hellman-group18-sha512 если у вас политика «покрепче» и клиенты точно современные

Смысл: curve25519 — быстрый и широко поддерживаемый вариант, а группы 16/18 — приемлемый fallback без возврата к слабым sha1-группам.

Что обычно стоит исключать

• diffie-hellman-group1-sha1 и diffie-hellman-group14-sha1 — это типичный «якорь легаси», который тянет вас в сторону SHA-1.
• diffie-hellman-group-exchange-sha1 — тоже нежелателен.

Если у вас внезапно есть зависимость от sha1-KEX, это повод не «оставить навсегда», а выделить отдельный вход (например, отдельный порт/подсеть/бастион) и запланировать миграцию клиентов.

Если SSH — одна из ключевых точек доступа в инфраструктуру, удобно вынести bastion на отдельный сервер и уже на нём держать «истину» по алгоритмам и аудитам. Для такого сценария обычно логичнее использовать VDS, чтобы не упираться в ограничения окружения и иметь полный контроль над сетевыми правилами и журналированием.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Host keys: HostKeyAlgorithms и набор ключей на сервере

HostKeyAlgorithms определяет, какими ключами сервер может представляться клиенту. На практике это про набор файлов ssh_host_* и то, что разрешено для презентации.

Что держать на сервере в 2026-м

• Ed25519 — почти всегда основной: быстрый, компактный, удобный.
• ECDSA P-256 — часто как дополнительный для совместимости (иногда требуется политиками).
• RSA — только если у вас есть реальная потребность в легаси, и при этом вы ограничиваете подписи до SHA-2 (см. ниже про PubkeyAcceptedAlgorithms).

Если вы ещё храните DSA hostkey — это уже не «совместимость», а техдолг: в нормальной конфигурации его быть не должно.

Практическая идея: два hostkey, один «современный» и один «для миграции»

Оставьте Ed25519 как основной, а RSA — только как временный мост для клиентов, которые не умеют Ed25519 (да, такие ещё встречаются в старых вендорских устройствах и древних библиотечных сборках).

Если хотите ещё сильнее «поджать» профиль (включая шифры и MAC) и получить цельную политику на весь стек согласования, держите под рукой отдельный разбор по параметрам SSH: сильные ciphers/KEX/MAC для OpenSSH без сюрпризов.

Пользовательские ключи и подписи: PubkeyAcceptedAlgorithms и конец ssh-rsa

Параметр PubkeyAcceptedAlgorithms — один из самых «ломающих» при hardening. Он отвечает не за тип ключа как файла, а за алгоритм подписи в аутентификации.

Главное правило

RSA-ключ может быть нормальным, но подпись ssh-rsa (RSA + SHA-1) — нет. Современный OpenSSH использует rsa-sha2-256 и rsa-sha2-512, и именно их стоит разрешать, если RSA вам нужен.

Минимальный набор для современных ключей

• ssh-ed25519
• ecdsa-sha2-nistp256 (если используете ECDSA)
• rsa-sha2-256, rsa-sha2-512 (если есть RSA)
• sk-ecdsa-sha2-nistp256@openssh.com и/или sk-ssh-ed25519@openssh.com для FIDO2

Если вы хотите «резать по-живому», начните с запрета ssh-rsa, но оставьте RSA SHA-2 — так вы часто сохраняете работоспособность CI и старых ключей без отката в SHA-1.

SSH CA и CASignatureAlgorithms: как не подложить себе свинью

Если вы используете SSH-сертификаты (через TrustedUserCAKeys), то обязательно проверьте CASignatureAlgorithms. Это ограничение алгоритмов подписи, которыми CA подписывает пользовательские/хостовые сертификаты.

Почему это важно

Даже если вы «везде Ed25519», можно случайно продолжать выпускать сертификаты CA подписью, которую вы бы уже не хотели видеть. Ограничение на стороне сервера даёт гарантию: сертификаты, подписанные «не тем», просто не будут приняты.

Практический подход

• Если CA-ключ Ed25519 — ограничьте CASignatureAlgorithms на Ed25519 (и, при необходимости, на RSA SHA-2).
• Если CA-ключ RSA — разрешайте только rsa-sha2-256/rsa-sha2-512.
• Не оставляйте «как есть» в надежде, что дефолты вас спасут: в мультикомандной инфраструктуре дефолты часто живут слишком долго.

Тонкость: CASignatureAlgorithms — это про подпись сертификата CA, а не про алгоритм ключа конечного пользователя. Поэтому при миграции удобно заранее проверить, чем именно подписываются сертификаты, и какой срок жизни/ротации у них заложен.

FIDO2 в OpenSSH: что такое security key и как это выглядит в проде

FIDO2 (security keys) в OpenSSH — это аппаратно защищённая пара ключей, где приватная часть не покидает устройство. В конфиге и логах вы будете видеть алгоритмы семейства sk-*, например sk-ecdsa.

Плюсы для админа/DevOps

• Сильная защита от кражи приватного ключа: даже если агент/диск/бэкап утечёт, ключа «как файла» нет.
• Удобно комбинировать с политиками типа «только сертификаты» или «только для привилегированных пользователей».
• Хорошо ложится на Zero Trust: физическое присутствие устройства + PIN/Touch (в зависимости от модели).

Типовые подводные камни

• Некоторые headless-процессы (CI) не смогут использовать FIDO2 без отдельной архитектуры доступа (jump host, краткоживущие сертификаты, отдельные ключи для автоматики).
• На серверах убедитесь, что PubkeyAcceptedAlgorithms включает нужные sk-* алгоритмы, иначе ключи будут «как будто не работают».
• Продумайте восстановление доступа: запасные ключи, break-glass аккаунт, временные сертификаты.

Пример «жёсткой» конфигурации (скелет) для современных клиентов

Ниже — ориентир. Он не универсален: перед применением сверяйте с вашей версией OpenSSH и реальными клиентами. Все значения лучше проверять через sshd -T после внесения.

# /etc/ssh/sshd_config (фрагмент)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256
PubkeyAcceptedAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-256,rsa-sha2-512
CASignatureAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512

Обратите внимание: включение rsa-sha2-* не означает, что вы «разрешили старый RSA». Это означает, что вы разрешили RSA с SHA-2, а не с SHA-1.

Совместимость с legacy clients: как делать исключения правильно

Почти в любой инфраструктуре найдётся легаси: старые образы, вендорские устройства, «встроенный» SSH-клиент в каком-нибудь агенте. Важно не опускать криптографию для всех, а локализовать исключение.

Стратегия 1: отдельный порт под легаси

Вы поднимаете второй экземпляр sshd (или второй порт) с более мягкими алгоритмами и ограничиваете доступ к нему сетевыми правилами. Так вы не смешиваете политики в одном месте. Это самый предсказуемый способ, но требует аккуратной эксплуатации.

Стратегия 2: Match по подсети/пользователю

Если легаси известно и ограничено (например, подсеть офисных терминалов или конкретный пользователь для интеграции), используйте Match Address или Match User и расширяйте список алгоритмов только внутри блока.

# Пример: смягчение только для одной подсети
Match Address 192.0.2.0/24
  KexAlgorithms +diffie-hellman-group14-sha256
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +rsa-sha2-256,rsa-sha2-512

Даже в «легаси»-блоке лучше сначала пробовать добавить rsa-sha2-* и sha256-группы, а не возвращать ssh-rsa и sha1-KEX. Возврат ssh-rsa оставляйте последним шагом и только для очень старых клиентов, которые иначе никак.

Проверка и аудит: что гонять перед релизом и после

Локальная проверка конфигурации

sshd -t
sshd -T | sed -n 's/\(kexalgorithms\|hostkeyalgorithms\|pubkeyacceptedalgorithms\|casignaturealgorithms\).*/&/p'

Если sed не подходит — просто найдите строки вручную в выводе sshd -T. Смысл в том, чтобы документировать итоговую политику именно так, как её видит sshd.

Проверка с клиента

Полезно уметь диагностировать «почему не сошлось». На клиенте увеличьте verbosity:

ssh -vv user@server

В выводе обычно видно, на каком шаге negotiation произошёл конфликт: KEX, hostkey или подпись пользователя.

Аудит сторонним инструментом

В задачах hardening часто всплывает ssh-audit. Логика простая: инструментом фиксируете, какие алгоритмы реально предлагает сервер, и сверяете это с вашей политикой. В идеале вы получаете короткий список современных алгоритмов без «исторических хвостов».

Если вы параллельно приводите в порядок внешние сервисы (панели, окружения, доступы админов) и хотите упростить эксплуатацию, часто помогает вынести критичные роли на отдельные серверы и разграничить доступы. В таких случаях удобно держать инфраструктурные сервисы на VDS, а проекты, где нужен только веб-стек, размещать на виртуальном хостинге.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Чеклист внедрения (короткий, но практичный)

1. Снимите текущий «слепок»: sshd -T и список имеющихся host keys.
2. Определите, используете ли SSH CA и какими подписями выпускаются сертификаты: это влияет на CASignatureAlgorithms.
3. Сформируйте «modern profile» (без SHA-1) и примените сначала на bastion/стейджинге.
4. Если есть легаси — оформите исключение через Match или отдельный порт, не трогая общий профиль.
5. Добавьте FIDO2-алгоритмы sk-* в PubkeyAcceptedAlgorithms там, где это нужно (обычно для админов).
6. Проверьте: sshd -t, новый вход с нескольких типов клиентов, затем аудит.

Итог: «жёстко» — это не про запреты, а про управляемость

В 2026 году хорошая настройка OpenSSH — это когда у вас:

• KexAlgorithms и HostKeyAlgorithms ограничены современными, понятными вариантами;
• PubkeyAcceptedAlgorithms не допускает ssh-rsa, но при необходимости оставляет RSA с SHA-2;
• CASignatureAlgorithms зафиксирован под вашу CA-политику и не принимает «случайные» подписи;
• FIDO2 (security keys) включены там, где это даёт максимальный выигрыш по рискам;
• совместимость с legacy clients оформлена точечно и документирована.

Такой подход повышает security и делает SSH предсказуемым сервисом: вы заранее знаете, что именно предлагаете клиентам и почему.