SSH hardening в 2026: какие настройки реально важны, а что уже карго-культ?

[fandango1305]

Наткнулся на очередную статью про SSH hardening — там список на две страницы: менять порт, запрещать root login, AllowUsers, MaxAuthTries, ClientAliveInterval, и ещё десяток настроек. Хочу разобраться что из этого реально даёт безопасность, а что просто ритуал 'потому что в гайде написано'. У нас несколько серверов с доступом по SSH, key-only, fail2ban стоит.

[lucky1000]

Если у вас уже key-only аутентификация — 90% угроз уже закрыто. PasswordAuthentication no это самое важное. Всё остальное — тонкая настройка. Смена порта реально снижает шум в логах, но безопасность не увеличивает — любой nmap найдёт за секунды.

[barbs]

Вот что я считаю реально важным помимо key-only:

PermitRootLogin no — обязательно, даже если ключи
AllowUsers или AllowGroups — явный whitelist пользователей
X11Forwarding no — если не нужен
PubkeyAuthentication yes + AuthenticationMethods publickey — явно

И в /etc/ssh/sshd_config.d/ держать отдельный файл чтобы не трогать основной конфиг.

MaxAuthTries 3 и ClientAliveInterval — это скорее защита от зависших сессий чем от атак.

Ещё важно: обновлять OpenSSH. В 2025-2026 было несколько CVE в старых версиях.

[grumpylurker]

@barbs, Смена порта — карго-культ с точки зрения безопасности, но реально полезная вещь с точки зрения signal-to-noise в логах. Я перенёс на нестандартный порт — fail2ban перестал вообще что-либо банить, в auth.log тишина. Не потому что атак нет, а потому что боты сканят 22 порт и дальше не идут.

[barbs]

Добавлю про Match блоки — очень мощная штука. Можно разрешить доступ только с определённых IP для отдельных пользователей:

Match User deploy Address 10.0.0.0/8
ForceCommand /usr/local/bin/deploy.sh
AllowTcpForwarding no

Для CI/CD деплойных ключей это must-have. Скомпрометированный deploy-ключ не даст интерактивный shell.

[sergeyserov]

@lucky1000, Что точно карго-культ: Protocol 2 — уже давно дефолт, Protocol 1 выпилен из OpenSSH 7+. Ещё видел в гайдах UsePrivilegeSeparation yes — тоже дефолт и даже deprecated в новых версиях. Люди копипастят это из статей 2012 года.

[PyLover]

Для СНГ-серверов особенно важно: если сервер в России/Украине/Казахстане — сканирование идёт и из местных сетей, не только из Китая/США как обычно в примерах. fail2ban с bantime = 24h и findtime = 10m вполне достаточно. Ещё можно добавить ipset для блокировки целых AS которые только сканят.

[juniorredteam]

Добавлю то, чего в треде не хватает: сам sshd тоже бывает уязвим — regreSSHion в 2024-м это хорошо напомнил, и никакой AllowUsers тогда не спасал. Поэтому автообновления openssh-server важнее половины списка из гайдов. И вторая недооценённая вещь — гигиена ключей: ed25519 с passphrase и периодическая ревизия authorized_keys. Я у себя однажды нашёл живой ключ подрядчика, который ушёл два года назад.

[llama_maker]

@barbs, Match-блоки поддержу и добавлю уровень ниже: те же ограничения вешаются прямо в authorized_keys опциями from=, command=, no-pty, no-agent-forwarding. Удобно, когда нет рута или не хочется трогать sshd_config: деплой-ключ с command= не даст интерактивный шелл, даже если конфиг демона кто-то потом перепишет. Дублировать ограничение на двух уровнях — не паранойя, а дёшево.

[tor2000]

@grumpylurker, чистый auth.log — это приятно, но у смены порта есть цена: из гостевых и корпоративных сетей нестандартные порты часто закрыты на исход, и ты сам себе отрезаешь доступ из отеля или офиса заказчика. Я в итоге вместо этого спрятал SSH за WireGuard: наружу торчит только UDP, который сканеры толком не видят, а 22-й слушает на интерфейсе туннеля. Тишина та же, костылей меньше.