SSH безопасность: правильная настройка Linux-серверов

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет администрирования Linux-инфраструктур я посмотрел тысячи журналов sshd и насмотрелся на всё: от скучных брутфорсов ботнетов до таргетированных атак с подменённым пакетом openssh. Хорошая новость: для 99% угроз достаточно простой дисциплины в настройках. Пройдёмся по чек-листу, который я применяю на каждом новом сервере с первой минуты.

Угрозы, от которых реально защищаемся

Когда админ спрашивает «а что мне грозит» — я отвечаю: боты. Массовые сканы 22-го порта с утечённых словарей. По нашим логам на обычный VPS прилетает 300–1500 попыток входа в сутки. Вторая угроза — украденный ключ разработчика или CI-раннера. Третья, самая серьёзная — таргетированная атака через фишинг, когда злоумышленник уже попал на рабочую станцию админа и пытается использовать его ssh-agent.

Чек-лист из 12 мер

Правильный sshd_config

# /etc/ssh/sshd_config
Port 58722
AddressFamily inet
ListenAddress 10.0.1.5

Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Криптография
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Аутентификация
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PubkeyAuthentication yes
AuthenticationMethods publickey

MaxAuthTries 3
MaxSessions 4
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2

# Ограничения
AllowGroups ssh-admins
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no
GatewayPorts no

# Логирование
LogLevel VERBOSE
SyslogFacility AUTH

Генерация ключей правильно

# Современный способ
ssh-keygen -t ed25519 -a 100 -C "boss@itfresh-$(date +%F)"

# Если нужен RSA (устаревшие системы)
ssh-keygen -t rsa -b 4096 -a 100 -C "boss@itfresh-$(date +%F)"

# Передача публичного ключа на сервер
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 58722 boss@server.corp.ru

# Пароль на приватный ключ — обязательно!

Я всегда ставлю пароль на ключ и использую ssh-agent с таймаутом. Украсть файл ключа без пароля — бесполезно.

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

sudo apt install libpam-google-authenticator
su - admin
google-authenticator -t -d -f -r 3 -R 30 -W
# Запоминаем QR-код в приложении Authy/FreeOTP

# /etc/pam.d/sshd добавить строку
auth required pam_google_authenticator.so nullok

# /etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Теперь вход требует: правильный ключ + одноразовый код. Украсть оба одновременно почти невозможно.

Bastion-хост для прода

У нас на практике все продакшен-серверы сидят в приватной подсети дата-центра МТС, а в интернет смотрит только один bastion на Dell Xeon Platinum 8280. Между bastion и внутренними нодами — 40G Mellanox. Доступ снаружи только к bastion, дальше — через ProxyJump:

# ~/.ssh/config
Host bastion
  HostName bastion.corp.ru
  Port 58722
  User boss
  IdentityFile ~/.ssh/id_ed25519

Host db-* app-*
  ProxyJump bastion
  User boss
  IdentityFile ~/.ssh/id_ed25519

Port Knocking и hidden SSH

Если хотите сделать сервер «невидимым» для массовых сканов — настройте knockd. Порт SSH остаётся закрытым, открывается только после последовательности стуков по заданным портам.

sudo apt install knockd

# /etc/knockd.conf
[openSSH]
  sequence = 7077,8088,9099
  seq_timeout = 5
  command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 58722 -j ACCEPT
  tcpflags = syn

[closeSSH]
  sequence = 9099,8088,7077
  seq_timeout = 5
  command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 58722 -j ACCEPT
  tcpflags = syn

Мини-кейс: защита веб-студии

Весной 2025 к нам пришёл клиент — веб-студия с 8 серверами в облаке. Жалоба: «нас взломали, кто-то залил крипто-майнер на два продакшена». Разбор показал: аутентификация по паролю была включена, один разработчик использовал пароль «Qwerty2023», бот его подобрал за три дня. За 4 часа мы: перевели все 8 серверов на ключи Ed25519, поставили 2FA для всех админов, закрыли SSH через bastion в дата-центре МТС, включили fail2ban. Количество попыток на прод-хосты после этого обнулилось (они ушли в приватную подсеть), bastion фильтрует 800 ботовых попыток в день. Стоимость работ — 42 000 руб. за 2 дня.

Мониторинг и fail2ban

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 58722
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 86400
banaction = iptables-multiport

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Для серьёзного мониторинга я подключаю Wazuh agent — он отправляет все события sshd в SIEM с корреляцией по source IP.

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

• Оставили PasswordAuthentication yes «временно». Пароль — главная дырка, отключайте сразу.
• Root с ключом. Даже с ключом root не должен логиниться напрямую — используйте sudo.
• Одноразовый ключ для всех серверов. Компрометация одного — компрометация всех. Минимум разные ключи на разные окружения.
• Нет ротации. Ключи старше 2 лет — заменяем планово.
• Забыли про authorized_keys comment. Без комментария через год непонятно, чей это ключ и можно ли его удалить.

FAQ — частые вопросы по SSH-безопасности

Помогает ли смена стандартного SSH порта?

Уменьшает объём автоматических сканов и логов, но не защищает от целевой атаки. Это гигиена, а не безопасность.

Какие ключи использовать в 2025 году?

Ed25519 — оптимальный выбор: короткие, быстрые, стойкие. RSA допускается от 4096 бит.

Как настроить 2FA на SSH?

Через libpam-google-authenticator или FreeIPA+Duo. В sshd_config: AuthenticationMethods publickey,keyboard-interactive.

Что такое bastion-хост?

Промежуточный SSH-сервер, через который идёт доступ ко всем внутренним хостам.

Как мониторить попытки взлома SSH?

fail2ban + логи /var/log/auth.log + интеграция с Wazuh/Telegram.