sshd_config: безопасная настройка SSH и проверка командой sshd -T

Настройка SSH — одно из самых рискованных мест в администрировании: ошибка в sshd_config может отрезать вас от сервера, а неправильное понимание порядка директив даёт ложное чувство защиты: вы пишете PasswordAuthentication no, а в силе остаётся значение из другого файла. Ниже файл безопасных настроек, правила применения директив, проверка итоговой конфигурации командами sshd -t и sshd -T до перезапуска и порядок, при котором вы не потеряете доступ.

Статья опирается на логику направления «Управление доступом» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверки выполнены на OpenSSH 9.2 в Debian 12 командами sshd -t -f и sshd -T -f с временными файлами: служба и рабочие настройки не менялись. Дополнительно о защите входа: MFA для SSH, CrowdSec.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Правило, которое ломает настройки: первое значение побеждает

В OpenSSH для большинства директив действует первое найденное значение, а не последнее. На Debian и Ubuntu в начале основного файла стоит строка Include /etc/ssh/sshd_config.d/*.conf, поэтому файлы из каталога sshd_config.d читаются раньше остального файла и перекрывают его. Проверка двумя вариантами порядка:

Вывод: если вы правите основной sshd_config, а в sshd_config.d уже лежит файл (например, от автоматизации или хостинга), ваша строка может не действовать. Всегда проверяйте итог командой sshd -T, а не файл на глаз.

Файл настроек

Сохраните как /etc/ssh/sshd_config.d/10-hardening.conf (число в начале имени задаёт порядок чтения: меньшее читается раньше). Перед применением замените имена групп на существующие.

# /etc/ssh/sshd_config.d/10-hardening.conf
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 4
MaxStartups 10:30:60
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
PermitUserEnvironment no
LogLevel VERBOSE
AllowGroups ssh-users admins
Banner none

Match Group admins
    AllowTcpForwarding local

Match Address 203.0.113.0/24
    PasswordAuthentication no

Блоки Match

Блок Match переопределяет настройки для подходящих условий; он действует до следующего Match или конца файла. Размещайте его в конце файла. Проверка условий через sshd -T -C (имитация подключения):

Ограничения: внутри Match допустимы не все директивы (смотрите man sshd_config); для проверки блока с группой пользователь должен реально состоять в группе на тестовой машине.

Проверка до применения

1. Синтаксис. sudo sshd -t: тихо завершается без ошибок, если файл верен. При ошибке выводится файл и строка, например /tmp/sshd_bad.conf line 1: unsupported option "maybe". (так выглядит значение, которое директива не принимает).
2. Итоговые значения. sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|authenticationmethods|maxauthtries|allowgroups|allowtcpforwarding|loglevel)'. Сравните с задуманным. Пример результата на тестовом файле:

   permitrootlogin no
   passwordauthentication no
   authenticationmethods publickey
   maxauthtries 3
   allowtcpforwarding no
   loglevel VERBOSE
   allowgroups ssh-users
   allowgroups admins

3. Для конкретного пользователя и адреса. sudo sshd -T -C user=ИМЯ,host=h,addr=АДРЕС покажет значения с учётом Match.
4. Проверка новой конфигурации без применения. sudo sshd -t -f /путь/к/файлу и sshd -T -f /путь/к/файлу работают с произвольным файлом; в нём нужна строка HostKey (например, HostKey /etc/ssh/ssh_host_ed25519_key), иначе проверка сообщит об отсутствии ключей хоста.

Применение без потери доступа

1. Откройте вторую сессию SSH (или консоль гипервизора) и не закрывайте до окончания проверки. Перезагрузка службы не обрывает уже открытые сеансы.
2. Сделайте копию: sudo cp -a /etc/ssh/sshd_config.d /root/sshd_config.d.bak, sudo cp -a /etc/ssh/sshd_config /root/sshd_config.bak.
3. Проверьте: sudo sshd -t и sudo sshd -T (шаг выше). Убедитесь, что allowgroups содержит группу, в которой состоите, и что ваш ключ в authorized_keys.
4. Примените: sudo systemctl reload ssh (на Debian и Ubuntu служба называется ssh, на RHEL и Rocky — sshd).
5. Проверьте новое подключение из третьего окна, не закрывая существующих: ssh -o PreferredAuthentications=publickey пользователь@сервер. Убедитесь также, что вход по паролю действительно отклоняется: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no пользователь@сервер должен сообщить о недопустимом методе.
6. Откат при проблеме из открытой сессии: восстановить копии и выполнить sudo systemctl reload ssh.

Для особо рискованных изменений используйте автоматический откат (отложенный запуск прежней конфигурации средствами systemd): карточка изменения и план отката.

Алгоритмы шифрования

Современный OpenSSH по умолчанию предлагает разумный набор алгоритмов (на тестовой системе по умолчанию включены, в частности, curve25519-sha256 и chacha20-poly1305); перечень поддерживаемых ваших версией можно посмотреть командами ssh -Q kex, ssh -Q cipher, ssh -Q mac. В списке есть устаревшие значения (например, diffie-hellman-group1-sha1), но поддерживаемое не значит предлагаемое по умолчанию: в итоге смотрите sshd -T | grep -E '^(kexalgorithms|ciphers|macs)'. Менять алгоритмы вручную нужно только если требует политика или сканер, и после проверки совместимости клиентов; неверно составленный список отсечёт старые клиенты.

Ключи и учётные записи

• Для входа используйте ключи Ed25519 и защиту ключа парольной фразой; на рабочих местах храните ключи на аппаратных токенах, если возможно.
• Ограничивайте ключи в authorized_keys параметрами (from="адрес", command="...", no-port-forwarding) для служебных ключей.
• Удаляйте ключи при увольнении сотрудника: отзыв прав при увольнении.
• Не открывайте SSH в интернет без необходимости: доступ через VPN, ограничение по адресам: WireGuard, firewall.
• Проверяйте журналы входов: правила Wazuh для SSH.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление доступом» (материалы направления, карта зрелости) и поддерживает «Безопасность конечных устройств». Уровень 2 требует прав по ролям и минимуму, MFA и защищённого удалённого и привилегированного доступа: безопасная настройка SSH — прямая часть этого.

Как проверить

1. sshd -T показывает ожидаемые значения: root запрещён, пароли отключены, ограничены попытки, пересылка выключена.
2. Вход по ключу работает под личной учётной записью, вход по паролю и под root отклоняется.
3. Вне открытой сессии пробный вход выполнен до закрытия аварийного доступа, копии конфигурации сохранены.
4. Журнал входов собирается на сервер сбора и по нему настроены оповещения.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Руководство OpenSSH: man sshd_config, man sshd для вашей версии; сайт проекта: openssh.com.
• CIS Benchmarks для вашего дистрибутива (раздел о конфигурации SSH): cisecurity.org. Международная практика, не российский норматив.