SSH Hardening: безопасная настройка сервера от взлома

SSH — основной способ администрирования Linux-серверов и главная мишень автоматизированных атак. Грамотный hardening снижает риск взлома на 95%.

Базовая конфигурация /etc/ssh/sshd_config

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowUsers deploy admin
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group14-sha256
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

sshd -t && systemctl reload sshd

Не закрывайте текущую сессию! После изменения порта откройте новое соединение в другой вкладке. Убедитесь что вход работает — только потом закрывайте старую сессию.

Генерация и настройка SSH-ключей

ssh-keygen -t ed25519 -C "server-key-2026" -f ~/.ssh/myserver_ed25519
ssh-copy-id -i ~/.ssh/myserver_ed25519.pub -p 22 user@server

Двухфакторная аутентификация (TOTP)

apt install libpam-google-authenticator -y
google-authenticator

Добавить в /etc/pam.d/sshd: auth required pam_google_authenticator.so

В sshd_config: ChallengeResponseAuthentication yes и AuthenticationMethods publickey,keyboard-interactive

Чеклист SSH Hardening

Настройка	Значение	Приоритет
Нестандартный порт	2222 или другой	Средний
PermitRootLogin no	Обязательно	Высокий
PasswordAuthentication no	После настройки ключей	Высокий
AllowUsers	Только нужные	Высокий
MaxAuthTries 3	Ограничить попытки	Средний
fail2ban	Блокировка атакующих IP	Высокий
2FA (TOTP)	Дополнительный фактор	Средний

Мониторинг попыток входа

journalctl -u ssh --since "1 hour ago" | grep "Failed"
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20
fail2ban-client status sshd

Максимальная защита: Не открывайте SSH в интернет вообще. Используйте Cloudflare Access или WireGuard VPN как прослойку — SSH доступен только через защищённый туннель.

Типичные ошибки при hardening

Ошибка	Причина	Что делать
sshd: no hostkeys available -- exiting	Синтаксическая ошибка в конфиге либо отсутствуют файлы ключей хоста после переустановки	Проверьте конфиг: `sshd -t`, при необходимости сгенерируйте ключи: `ssh-keygen -A`
Permission denied (publickey)	После отключения PasswordAuthentication публичный ключ не скопирован или у ~/.ssh неверные права	Проверьте права: `chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys`
Address already in use	Указанный порт уже занят другим процессом или старым экземпляром sshd	Найдите процесс: `ss -tlnp \| grep 2222` и остановите конфликтующий сервис
Connection refused на новом порту	Файрволл (ufw/iptables) не открыт для нового порта SSH	Разрешите порт: `ufw allow 2222/tcp` до перезапуска sshd
WARNING: UNPROTECTED PRIVATE KEY FILE! на клиенте	Права на файл приватного ключа на локальной машине слишком открытые	Исправьте права: `chmod 600 ~/.ssh/myserver_ed25519`

Сравнение методов защиты SSH

Метод	Защищает от	Сложность внедрения
Смена порта	Автоматизированного сканирования «по умолчанию»	Низкая, но не спасает от целевой атаки
fail2ban	Брутфорса по логам неудачных попыток	Низкая, ставится за 5 минут
2FA (TOTP)	Кражи или утечки приватного ключа	Средняя, нужен телефон у каждого администратора
Port knocking / SPA	Разведки порта сканерами (порт вообще не виден)	Высокая, сложнее диагностировать проблемы подключения

Когда hardening не спасёт

0-day уязвимость в самом OpenSSH — никакая конфигурация не закроет баг в коде демона
Скомпрометированная рабочая станция администратора с приватным ключом на диске — атакующий получит доступ, минуя все настройки сервера
Инсайдер с легитимным доступом и собственным ключом — hardening защищает от внешних атак, а не от злоупотребления правами
Слабый пароль sudo при физическом или консольном доступе к серверу (например, через панель провайдера) — SSH тут не единственная точка входа

Для защиты от брутфорса дополнительно ставится Fail2ban: защита SSH и Nginx от подбора паролей, а более сильный второй фактор разобран в статье «Двухфакторная аутентификация для SSH и веб-панелей».

Проверка результата

После настройки проверьте, что все параметры реально применились:

# Показать активную (не файловую, а применённую) конфигурацию
sshd -T | grep -Ei "permitrootlogin|passwordauthentication|port|maxauthtries"

# Убедиться, что вход по паролю действительно отклоняется
ssh -o PubkeyAuthentication=no -o PasswordAuthentication=yes user@server
# Ожидаемый результат: "Permission denied (publickey)"

# Проверить, что старый порт 22 закрыт снаружи
nmap -p 22,2222 server_ip

Если SSH нужно вообще спрятать от сканеров, следующий шаг — вынести его за WireGuard VPN на VPS и открывать порт только внутри туннеля.

Частые вопросы

Что делать, если после сохранения новой конфигурации подключение по SSH вообще не устанавливается?

Если новая конфигурация не даёт подключиться, первым делом нужно проверить синтаксис файла командой sshd -t и посмотреть, не остался ли открытым старый порт в другой вкладке терминала — именно поэтому старую сессию советуют не закрывать до проверки новой. При полной потере доступа остаётся консоль провайдера или панель виртуализации, через которую можно вернуть прежние значения конфигурации.

Безопасно ли использовать один и тот же приватный ключ для доступа к нескольким серверам?

Использовать один приватный ключ для нескольких серверов технически работает, но противоречит принципу изоляции: утечка этого единственного ключа с рабочей станции администратора сразу открывает доступ ко всем серверам сразу, а не к одному. Удобнее и безопаснее создавать отдельную пару ключей под каждый сервер или хотя бы под каждую роль доступа.

Нужно ли сразу отключать пароль (PasswordAuthentication), если двухфакторная аутентификация ещё не настроена?

Отключать пароль стоит только после того, как вход по ключу уже проверен и работает, иначе при любой ошибке в настройке ключей администратор рискует потерять доступ к серверу до этого момента. Двухфакторную аутентификацию логично настраивать как дополнительный слой уже над рабочим входом по ключу, а не вместо временного пароля.

Как восстановить доступ к серверу, если AllowUsers указан неверно и вход закрылся для всех пользователей?

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