Настройка безопасности SSH на Linux: полное руководство по защите сервера

SSH — это главный инструмент удалённого управления Linux-серверами. И именно поэтому он под постоянным огнём. Каждый день тысячи ботов методично сканируют весь интернет в поисках открытого 22-го порта, пробуя admin/admin, root/123456 и сотни других комбинаций. Но даже в изолированной корпоративной сети расслабляться не стоит: злоумышленник внутри периметра может делать по одной попытке в минуту — тихо, без алертов — и через несколько месяцев получить полный доступ. В этой статье пройдёмся по всем ключевым методам защиты SSH-сервера: от базовых настроек sshd_config до двухфакторной аутентификации и аудита подключений.

Почему стандартная конфигурация SSH опасна?

Типичный SSH-сервер после установки настроен так, чтобы просто работало. О безопасности там никто не думал. Вот что вы получаете «из коробки» на большинстве дистрибутивов:

• Порт 22 — стандартный, боты ломятся туда в первую очередь
• Парольная аутентификация — открытое приглашение для брутфорса
• Разрешён вход root — атакующему достаточно угадать один пароль, и сервер его
• Нет ограничения попыток — перебирай хоть миллион комбинаций
• Прослушивание на всех интерфейсах — SSH торчит наружу со всех сетевых адресов

Один такой сервер в сети без файрвола — это буквально незапертая дверь. Идём по шагам, закрываем всё.

Как перейти на авторизацию по SSH-ключам?

Ключевая аутентификация — первое, что нужно настроить. Без вариантов. Она полностью закрывает тему брутфорса паролей: нет пароля — нечего перебирать. Алгоритм ed25519 на сегодня самый удачный выбор: короткий ключ, высокая скорость, хорошая криптостойкость.

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

Всё, что ниже, делается на вашей рабочей машине — не на сервере:

ssh-keygen -t ed25519 -C "admin@company.ru"

Когда генератор спросит passphrase — задайте его. Да, это лишние три секунды при каждом подключении, но если ключ утечёт, без пароля он будет бесполезен для атакующего.

Копирование ключа на сервер

# Автоматическое копирование
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Или вручную
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

После того как скопировали ключ на сервер, сразу проверьте подключение — оно должно пройти без запроса пароля:

ssh user@server

Отключение парольной аутентификации

Зашли без пароля — отлично. Теперь открываем /etc/ssh/sshd_config и правим:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Применяем изменения:

sudo systemctl restart sshd

Какие параметры sshd_config нужно изменить в первую очередь?

Файл /etc/ssh/sshd_config — это и есть точка управления всей безопасностью SSH. Вот параметры, которые нужно выставить обязательно:

# Привязка к конкретному IP (не ко всем интерфейсам)
ListenAddress 192.168.1.10

# Смена стандартного порта
Port 54322

# Только протокол версии 2
Protocol 2

# Запрет входа root
PermitRootLogin no

# Время на аутентификацию — 10 секунд
LoginGraceTime 10

# Максимум попыток аутентификации за сессию
MaxAuthTries 3

# Максимум одновременных сессий
MaxSessions 3

# Отключить пустые пароли
PermitEmptyPasswords no

# Отключить X11-проброс (если не нужен)
X11Forwarding no

# Отключить TCP-форвардинг (если не нужен)
AllowTcpForwarding no

# Разрешить вход только определённым пользователям
AllowUsers admin deploy

# Баннер предупреждения
Banner /etc/ssh/banner.txt

Зачем менять порт SSH и как это сделать правильно?

Смена порта не спасёт от целенаправленной атаки — это правда. Но она мгновенно отсекает 99% автоматических сканеров, которые ломятся только на 22-й. Минута работы, заметный эффект.

# /etc/ssh/sshd_config
Port 54322

Важный момент: откройте новый порт в файрволе до перезагрузки SSH, иначе рискуете сами себя заблокировать:

# Для UFW
sudo ufw allow 54322/tcp
sudo ufw delete allow 22/tcp

# Для iptables
sudo iptables -A INPUT -p tcp --dport 54322 -j ACCEPT
sudo iptables -D INPUT -p tcp --dport 22 -j ACCEPT

Как правильно настроить правила файрвола — разобрали отдельно: iptables: настройка файрвола в Linux.

После перезагрузки SSH указывайте порт явно:

ssh -p 54322 user@server

Как настроить Fail2Ban для защиты от брутфорса?

Fail2Ban анализирует логи и блокирует IP-адреса после нескольких неудачных попыток входа. Это обязательный инструмент для любого Linux-сервера.

Установка

# Debian/Ubuntu
sudo apt install fail2ban -y

# CentOS/RHEL
sudo yum install epel-release -y
sudo yum install fail2ban -y

Настройка jail для SSH

Создайте файл /etc/fail2ban/jail.local — именно его, не трогайте jail.conf: при обновлении пакета он перезапишется и все настройки слетят.

[sshd]
enabled = true
port = 54322
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
ignoreip = 127.0.0.1/8 192.168.1.0/24

Что означает каждый параметр:

• maxretry = 3 — три неудачи подряд, и IP улетает в бан
• bantime = 3600 — бан на час (3600 секунд), затем автоматически снимается
• findtime = 600 — эти три попытки считаются в рамках 10-минутного окна
• ignoreip — белый список: обязательно впишите свои IP, иначе можете заблокировать себя

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Проверка статуса

# Статус всех jail
sudo fail2ban-client status

# Детали по SSH
sudo fail2ban-client status sshd

# Разблокировать конкретный IP
sudo fail2ban-client set sshd unbanip 10.0.0.5

Как настроить двухфакторную аутентификацию SSH?

Двухфакторная аутентификация (2FA) — это одноразовый код поверх ключа или пароля. Украли ключ? Без второго фактора он всё равно не работает. На практике это очень хорошо останавливает атаки даже при компрометации учётных данных.

Установка Google Authenticator

sudo apt install libpam-google-authenticator -y

Запускаем настройку от имени обычного пользователя, не root:

google-authenticator

Мастер задаст несколько вопросов — отвечайте так:

• Time-based tokens — да (y)
• Update .google_authenticator — да (y)
• Disallow multiple uses — да (y)
• Rate limiting — да (y)

QR-код сканируйте любым совместимым приложением: Google Authenticator, Authy, Microsoft Authenticator. И сразу сохраните резервные коды — без них при потере телефона не войдёте.

Настройка PAM и SSHD

В файл /etc/pam.d/sshd добавляем строку:

auth required pam_google_authenticator.so

В /etc/ssh/sshd_config правим:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Перезапускаем SSH:

sudo systemctl restart sshd

Как ограничить доступ по IP и подсетям?

Помимо ListenAddress в sshd_config, есть ещё пара механизмов для ограничения доступа на уровне сети:

Через AllowUsers с привязкой к IP

# Разрешить admin только с определённой подсети
AllowUsers admin@192.168.1.*

# Несколько пользователей с разных адресов
AllowUsers admin@192.168.1.* deploy@10.0.0.*

Через TCP Wrappers

В файл /etc/hosts.allow:

sshd: 192.168.1.0/255.255.255.0
sshd: 10.0.0.0/255.255.255.0

В файл /etc/hosts.deny:

sshd: ALL

Через UFW/iptables

# Разрешить SSH только из офисной подсети
sudo ufw allow from 192.168.1.0/24 to any port 54322 proto tcp
sudo ufw deny 54322/tcp

Эти два файла хорошо работают в связке с правилами iptables — получается несколько независимых уровней фильтрации, и чтобы пробиться, атакующему нужно обойти каждый из них.

Как настроить аудит SSH-подключений?

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

Основные команды аудита

# Последние успешные входы
last -n 20

# Неудачные попытки
sudo lastb -n 20

# Кто сейчас подключён
who
w

# Лог SSH в реальном времени
sudo tail -f /var/log/auth.log

# Для systemd
sudo journalctl -u sshd -f

Расширенное логирование в sshd_config

# Уровень логирования
LogLevel VERBOSE

При уровне VERBOSE в лог попадают отпечатки ключей — это позволяет понять, чей именно ключ использовался при подключении:

# Пример лога
Accepted publickey for admin from 192.168.1.50 port 43210 ssh2: ED25519 SHA256:xxxxxxxxxxx

Про полноценный мониторинг Linux-серверов писали отдельно — смотрите статью Мониторинг Debian-сервера.

Какие дополнительные меры безопасности SSH существуют?

Базовые настройки сделали — теперь про продвинутые техники, которые используем в реальных проектах:

SSH-ловушка (Tarpit / Endlessh)

Endlessh — программа, которая висит на порту 22 и бесконечно медленно отправляет SSH-баннер. Боты «застревают» в ней на часы, не мешая реальному SSH на другом порту.

sudo apt install endlessh -y
# Настройте на порт 22, а реальный SSH — на нестандартный порт

Ограничение криптографических алгоритмов

# /etc/ssh/sshd_config — только современные алгоритмы
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
HostKeyAlgorithms ssh-ed25519

Автоматическое отключение неактивных сессий

# Отключать после 5 минут неактивности
ClientAliveInterval 300
ClientAliveCountMax 0

Как безопасно настроить межсерверное SSH-взаимодействие?

Бэкапы, деплой, репликация баз — всё это требует, чтобы серверы подключались друг к другу автоматически, без ввода пароля. Как сделать это правильно, не создавая дыру в безопасности:

1. Создайте отдельного пользователя с минимальными правами (например, backup-agent)
2. Сгенерируйте ключи на сервере-источнике: ssh-keygen -t ed25519
3. Скопируйте ключ на целевой сервер: ssh-copy-id backup-agent@target-server
4. Ограничьте команды в authorized_keys на целевом сервере:

# ~/.ssh/authorized_keys на целевом сервере
command="/usr/local/bin/backup-only.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA... backup-agent@source

Параметр command= — штука полезная. Он разрешает выполнение строго одной команды, и даже если ключ утёк, злоумышленник просто не получит полноценный shell. Проверено на практике не раз.

Как проверить текущую безопасность SSH-сервера?

Всё настроили? Прогоните проверку, прежде чем считать задачу закрытой:

Тестирование конфигурации

# Проверка синтаксиса sshd_config
sudo sshd -t

# Показать активную конфигурацию
sudo sshd -T | grep -i "passwordauthentication\|permitrootlogin\|port\|listenaddress"

Аудит с помощью ssh-audit

# Установка
pip3 install ssh-audit

# Запуск аудита
ssh-audit localhost:54322

ssh-audit — наш стандартный финальный шаг. Утилита выдаёт список используемых алгоритмов, тут же сигнализирует об уязвимостях и предлагает конкретные рекомендации. Пять минут работы, а картина сразу становится ясной.

Чеклист безопасности SSH

• Авторизация по ключам — включена
• Парольная аутентификация — отключена
• Вход root — запрещён
• Порт — нестандартный
• Fail2Ban — настроен и работает
• AllowUsers — список пользователей жёстко ограничен
• LogLevel — VERBOSE
• 2FA — настроена (на критичных серверах это не обсуждается)
• Файрвол — SSH разрешён только из доверенных подсетей

Часто задаваемые вопросы (FAQ)