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

[luka_crypto]

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

[valera6777]

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

[denis9127]

Вот что я считаю реально важным помимо 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 в старых версиях.

[zhenya_x]

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

[kirill_net]

Добавлю про 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.

[vectortcp6491]

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

[mark_ml]

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