Укрепляем OpenSSH: пошаговая настройка безопасности сервера

Введение / Зачем это нужно

OpenSSH по умолчанию настроен для удобства, а не для максимальной безопасности. Такая конфигурация оставляет сервер открытым для автоматических сканеров и брутфорс-атак, которые ежедневно пытаются подобрать доступ стандартными словарями.

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

Требования / Подготовка

Перед началом убедитесь, что у вас есть:

• Доступ к серверу с правами root или пользователя из группы sudo
• Резервная копия текущей конфигурации: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
• Установленный SSH-клиент на вашем локальном компьютере
• Чёткое понимание того, что после отключения парольного входа вы не сможете зайти без настроенного ключа

⚠️ Важно: Всегда проверяйте работоспособность SSH в новом окне терминала перед закрытием текущей сессии. Это спасёт вас от блокировки сервера при случайной опечатке в конфигурации.

Шаг 1: Генерация и настройка аутентификации по ключам

Ключи шифрования надёжнее паролей любой длины. Мы используем алгоритм Ed25519, который обеспечивает высокую скорость проверки и современную криптографическую стойкость.

1. На локальной машине сгенерируйте пару ключей:

ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_fix

2. Установите строгие права доступа к закрытому ключу:

chmod 600 ~/.ssh/id_ed25519_fix
chmod 700 ~/.ssh

3. Скопируйте публичный ключ на удалённый сервер:

ssh-copy-id -i ~/.ssh/id_ed25519_fix.pub user@server_ip

Убедитесь, что вход по ключу проходит успешно, прежде чем двигаться дальше.

Шаг 2: Отключение уязвимых параметров в sshd_config

Откройте конфигурационный файл демона SSH в текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Найдите следующие директивы и измените их значения. Если строки отсутствуют, добавьте их явно:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
PermitEmptyPasswords no

• PermitRootLogin no — запрещает прямой вход под суперпользователем.
• PasswordAuthentication no — полностью отключает уязвимый метод входа по паролям.
• X11Forwarding no — отключает перенаправление графического интерфейса, если вам не нужна удалённая графика.

Сохраните файл и выйдите из редактора.

Шаг 3: Ограничение пользователей и управление сессиями

Разрешайте доступ только тем учётным записям, которым он действительно необходим. Добавьте в конец sshd_config:

AllowUsers admin deployer
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3

• AllowUsers — явный белый список аккаунтов. Все остальные соединения будут отклонены на этапе аутентификации.
• ClientAliveInterval 300 и MaxAuthTries 3 — сервер разорвёт неактивные сессии через 5 минут и ограничит количество попыток ввода, срывая работу ботов.

Примените изменения, сначала проверив синтаксис:

sudo sshd -t

Если терминал вернул пустой вывод, ошибок нет. Перезапустите службу:

sudo systemctl restart sshd

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

Откройте новое окно терминала и попробуйте подключиться к серверу. Вход должен пройти автоматически по ключу. Для проверки безопасности выполните на сервере:

sudo journalctl -u sshd -f

Попробуйте подключиться с другого устройства без ключа или под пользователем, которого нет в AllowUsers. В логах вы должны увидеть отклонение соединения с кодом Authentication failed или Connection closed.

Возможные проблемы

Потеря доступа после применения настроек. Используйте веб-консоль хостинг-провайдера (VNC/KVM) или аварийный режим восстановления (Rescue System). Откройте sshd_config, временно верните PasswordAuthentication yes и перезапустите службу.

Ошибка Permission denied (publickey). Проверьте права на сервере. Папка ~/.ssh должна иметь права 700, а файл ~/.ssh/authorized_keys — 600. В системах с SELinux (RHEL, CentOS, AlmaLinux) выполните restorecon -Rv ~/.ssh.

Сервер не принимает соединения на нестандартном порту. Если вы сменили порт (директива Port), убедитесь, что правило разрешено в файрволе (ufw allow 1234/tcp или firewall-cmd --add-port=1234/tcp). SELinux также требует обновления контекста порта через semanage port -a -t ssh_port_t -p tcp 1234.