Безопасное управление сервером: почему SSH-ключи — это база, а пароли — ошибка

Новый VPS подвергается автоматическому сканированию и попыткам брутфорс-атак уже через 3–5 минут после назначения публичного IP-адреса. Боты непрерывно перебирают стандартные комбинации логинов и паролей по словарю, создавая паразитную нагрузку на демон SSH и засоряя системные журналы.

Оставлять открытым стандартный 22-й порт и использовать вход по паролю — критическая уязвимость инфраструктуры. В данном сатериале разберем последовательность базовой защиты (харденинга) сервера на базе Ubuntu/Debian.

Криптографический фундамент: генерация ключа ed25519

Современный стандарт безопасного удаленного доступа — асимметричный алгоритм ed25519. По сравнению с устаревающим RSA он обеспечивает повышенную криптографическую стойкость и высокую скорость генерации подписи при компактном размере ключа.

Сгенерируйте ключ на вашей локальной машине (не на сервере):

ssh-keygen -t ed25519 -C "admin-server-key"

Современный стандарт безопасного удаленного доступа — асимметричный алгоритм ed25519. По сравнению с устаревающим RSA он обеспечивает повышенную криптографическую стойкость и высокую скорость генерации подписи при компактном размере ключа.

Перенесите публичную часть ключа на сервер:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@ваш_ip_сервера

Критическое условие (права доступа)

Если ключ копируется вручную, файловая система Linux требует строгого разграничения прав. При избыточно открытых правах SSH-сервер сочтет конфигурацию небезопасной и заблокирует вход:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Проверьте вход по ключу:

ssh -i ~/.ssh/id_ed25519 root@ваш_ip_сервера

Пароль учетной записи запрашиваться больше не должен.

Харднинг конфигурации SSH (sshd_config)

После успешной проверки входа по ключу заблокируйте альтернативные векторы несанкционированного доступа на уровне демона SSH.

Откройте конфигурационный файл:

sudo nano /etc/ssh/sshd_config

(В современных дистрибутивах настройки можно выносить в отдельные файлы директории /etc/ssh/sshd_config.d/, но логика параметров сохраняется).

Внесите изменения в следующие директивы:

• Смена стандартного порта: Port 2222 (используйте любой свободный порт в диапазоне 1024–65535, чтобы снизить количество автоматического сканирования).

• Запрет входа по паролю: PasswordAuthentication no

• Запрет пустого пароля: PermitEmptyPasswords no

• Ограничение root-доступа: PermitRootLogin prohibit-password (разрешает вход суперпользователю только по SSH-ключу).

Примените конфигурацию:

sudo systemctl restart ssh

Правило безопасности: не закрывайте текущую активную сессию терминала. Откройте новое окно и проверьте подключение по новому порту: ssh -p 2222 root@ваш_ip_сервера. Если в синтаксисе допущена ошибка, вы сможете быстро исправить конфигурацию в первой открытой сессии

Настройка сетевого экрана UFW

Сетевой экран изолирует операционную систему, блокируя неиспользуемые порты на уровне ядра Linux.

# Базовая политика: запретить все входящие, разрешить все исходящие
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Разрешение только необходимых портов
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Активация сетевого экрана
sudo ufw enable

Проверьте статус и активность правил:

sudo ufw status verbose

Защита от брутфорса: установка и настройка Fail2ban

Даже при отключенной аутентификации по паролю сканеры продолжают посылать запросы на открытый порт, забивая очередь соединений и журнал auth.log. Сервис Fail2ban отслеживает неудачные попытки подключения и временно блокирует IP-адреса нарушителей на уровне сетевого экрана.

Установите пакет:

apt install fail2ban -y

Создайте локальный конфигурационный файл, чтобы обновления пакета не затерли ваши настройки:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Откройте /etc/fail2ban/jail.local и настройте секцию [sshd]:

[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 86400
findtime = 600

Конфигурация блокирует IP-адрес на 24 часа (86400 секунд) после 3 неудачных попыток подключения в течение 10 минут (600 секунд).

Перезапустите службу:

systemctl restart fail2ban

Проверьте статистику заблокированных IP:

sudo fail2ban-client status sshd

Модель сбоя: что делать, если ключ утерян?

Главная ошибка при переходе на SSH-ключи — отключить вход по паролю до проверки работоспособности самого ключа.

Если сессия прервалась, а ключ не работает, доступ по SSH будет потерян. Единственный способ его восстановить — авторизоваться через VNC/Web-консоль в панели управления хостингом, загрузиться в режиме восстановления, смонтировать корневой раздел и вручную изменить параметр на PasswordAuthentication yes в конфигурации SSH.

Порядок восстановления доступа:

1. Авторизуйтесь в панели управления хостинг-провайдера.

2. Откройте аварийную веб-консоль (VNC / Emergency Console), эмулирующую прямое подключение монитора и клавиатуры к серверу в обход сети.

3. Войдите под root-паролем, выданным хостером при создании виртуальной машины.

4. Откройте /etc/ssh/sshd_config, временно установите PasswordAuthentication yes, перезапустите службу (systemctl restart ssh) и добавьте новый рабочий публичный ключ.

Границы безопасности: почему харденинг не гарантирует анонимность

Отключение паролей, генерация ed25519-ключей и настройка Fail2ban полностью закрывают задачи защиты сервера от несанкционированного доступа и взлома. Однако эти меры не скрывают реальный IP-адрес администратора от системных журналов хостинга.

При каждом входе в консоль домашний IP фиксируется в файле /var/log/auth.log хост-машины. Если инфраструктура развернута под задачи, требующие строгой сетевой изоляции, прямое SSH-подключение компрометирует локацию. В таких сценариях необходимо применять правила цифровой гигиены и туннелирование SSH через netcat и SOCKS5.

Масштабирование: автоматизация безопасности на пуле серверов

При администрировании пула из 10–50 VPS под сетки сайтов или дропы ручной ввод команд на каждом хосте отнимает время и создает риск ошибок в конфигурациях Nginx и UFW. Развернуть защищенную сеть серверов в один клик позволяет готовый Ansible-плейбук с автосбросом прямых запросов по IP.

8. Чек-лист: проверка безопасности сервера перед запуском

• Сгенерирован локальный ключ ed25519 с кодовой фразой (passphrase).

• Проверены права доступа: 700 на каталог ~/.ssh и 600 на файл authorized_keys на сервере.

• Сменен стандартный порт SSH (директива Port 2222).

• Полностью отключена аутентификация по паролю (PasswordAuthentication no).

• Активирован сетевой экран UFW с закрытием всех портов, кроме явно разрешенных.

• Настроен и запущен сервис Fail2ban с активной защитой секции [sshd].

• Выполнена проверка входа в новом окне терминала без закрытия основной рабочей сессии.

9. Следующие шаги

• Для туннелирования SSH-трафика через SOCKS5 и защиты реального IP ➔ изучите правила цифровой гигиены сервера и изоляции веб-панелей.

• Для автоматической настройки безопасного окружения на десятках серверов ➔ используйте Ansible-playbook для массового развертывания LEMP.

• Для возврата к выбору конфигурации аппаратной среды ➔ перейдите к техническому гиду по типам хостинга от Виртуального до Выделенного.