Как защитить SSH на VPS от взлома

Почему SSH — это первоочередная задача по защите

SSH используется для управления сервером, поэтому он является основной целью для любой атаки. Как только VPS выходит в сеть, сканеры начинают подбирать имена пользователей и пароли на порту 22. Вы можете увидеть это в логах уже через несколько минут. Защита SSH заключается в устранении возможности подбора: необходимо полностью отключить вход по паролю, отключить вход для пользователя root и разрешить вход только по криптографическим ключам. После этого попытки подбора станут бесполезными, так как пароля не будет существовать.

Это предполагает, что SSH у вас уже настроен и работает. Если у вас есть доступ, вы можете его защитить. Выполняйте шаги строго по порядку. Не закрывайте текущую сессию, пока не убедитесь, что новая сессия работает корректно. Это предотвратит случайную блокировку доступа.

Шаг 1: Сначала убедитесь в работоспособности аутентификации по ключу

Аутентификация по ключу заменяет пароль на пару ключей: закрытый ключ хранится на вашем компьютере, а открытый ключ размещается на сервере. Сервер проверяет наличие закрытого ключа, при этом сам ключ не передается по сети. Перед отключением паролей убедитесь, что ключи работают, иначе вы потеряете доступ к системе.

Если у вас нет ключа, создайте его на своем компьютере:

ssh-keygen -t ed25519

Скопируйте открытую часть ключа на сервер:

ssh-copy-id user@your-server

Затем откройте новую SSH-сессию. Если вход выполнен без запроса пароля, значит, ключ работает и вы можете безопасно отключить аутентификацию по паролю. Если вы только начинаете работать с ключами или используете несколько компьютеров, в статье основы управления SSH-ключами подробно описана эта модель: по одному ключу на каждое устройство, требования sshd к правам доступа и порядок отзыва ключа при утере ноутбука.

Шаг 2: Усиление безопасности sshd с помощью drop-in файла

Не редактируйте /etc/ssh/sshd_config напрямую. Ubuntu 24.04 считывает drop-in файлы из /etc/ssh/sshd_config.d/. Маленький файл в этой директории удобнее: он сохраняется при обновлении пакетов и его легко удалить при возникновении проблем. Имя файла имеет значение: sshd использует первое прочитанное значение для каждой настройки. В облачных образах Ubuntu в этой директории уже находится 50-cloud-init.conf с параметром PasswordAuthentication yes. Назовите свой файл 00-, чтобы он шел раньше и имел приоритет; файл с именем 99- будет проигнорирован. Создайте файл:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Вставьте в него:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Каждая строка закрывает уязвимость. PasswordAuthentication no — самая важная настройка: при отключенных паролях у атаки методом перебора (brute-force) не будет цели. KbdInteractiveAuthentication no закрывает второй способ входа через пароль. PermitRootLogin no означает, что злоумышленник должен знать ваше имя пользователя и иметь ваш ключ, а не просто пытаться подобрать пароль к учетной записи root, которая есть в каждой системе.

Шаг 3: Проверка конфигурации и перезагрузка

Проверьте конфигурацию на наличие ошибок перед применением. Это предотвратит сбой сервиса из-за опечатки:

sudo sshd -t

Если вывод пуст, конфигурация верна. Перезагрузите SSH:

sudo systemctl reload ssh

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

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

В обоих случаях должен отображаться no. Теперь, не закрывая текущую сессию, откройте новую сессию в другом терминале. Если вход выполнен по вашему ключу, настройка завершена. Если возникла ошибка, ваша первая сессия остается открытой для исправления. Такое дублирование сессий служит защитой, поэтому никогда не пропускайте этот шаг.

Шаг 4: Необязательный нестандартный порт

Смена порта SSH с 22 на 2222 не повышает реальную безопасность, так как целевой злоумышленник сканирует все порты. Это действие лишь уменьшает объем шума в логах, так как большинство автоматизированных сканеров проверяют только порт 22. Если вам это необходимо, добавьте Port 2222 в ваш конфигурационный файл, сначала разрешите новый порт в firewall, затем выполните sudo systemctl daemon-reload && sudo systemctl restart ssh.socket и подключайтесь через ssh -p 2222. В Ubuntu 24.04 за прослушивание порта отвечает ssh.socket, поэтому обычный reload ssh оставляет sshd на порту 22; новый порт применится только после перезапуска сокета. Рассматривайте это как способ упорядочивания системы, а не как средство защиты.

Шаг 5: Дополнительные уровни защиты

Укрепленные SSH-ключи являются основой, поверх которой устанавливаются еще два уровня защиты.

Fail2ban анализирует логи и блокирует IP-адреса, которые совершают повторяющиеся неудачные попытки входа. Это снижает уровень шума от сканеров и блокирует их на ранних этапах. Этот метод эффективно работает при использовании только аутентификации по ключам: см. Настройка Fail2ban на Ubuntu для предотвращения SSH-атак.

Более надежный метод — полный запрет доступа к SSH из публичного интернета. Если вы развернете SSH через WireGuard VPN и ограничите доступ к порту 22 только внутри туннеля, пользователи вне VPN не смогут даже обнаружить сервис. В этом случае перебор паролей становится не просто сложным, а невозможным. Все эти меры предполагают использование межсетевого экрана с политикой запрета по умолчанию, например, настроенного UFW на VPS.

SSH — это лишь один пункт из общего списка действий: первые 10 минут на новом VPS содержат последовательность необходимых шагов, а автоматические обновления безопасности на Ubuntu обеспечивают своевременную установку патчей.

FAQ

Как отключить вход по паролю для SSH на Ubuntu 24.04?

Создайте drop-in файл в /etc/ssh/sshd_config.d/00-hardening.conf (префикс 00 обеспечит сортировку перед 50-cloud-init.conf, иначе приоритет будет у PasswordAuthentication yes, так как sshd использует первое прочитанное значение), содержащий PasswordAuthentication no и KbdInteractiveAuthentication no. Выполните sudo sshd -t для проверки, затем sudo systemctl reload ssh. Перед использованием убедитесь, что вход по ключу работает в новом сеансе. Редактирование drop-in файла вместо sshd_config позволяет сохранить настройки после обновления пакетов и упрощает откат изменений.

Стоит ли отключать вход для root через SSH?

Да. Установите PermitRootLogin no, чтобы никто не мог войти напрямую под пользователем root. Используйте обычного пользователя и команду sudo для выполнения административных задач. Пользователь root существует в любой Linux-системе, поэтому его доступность дает злоумышленнику известное имя пользователя для атаки. Отключение входа требует от атакующего знания вашего имени пользователя и наличия вашего ключа.

Повышает ли смена порта SSH безопасность сервера?

Существенно — нет. Перенос порта с 22-го скрывает вас от простых сканеров, которые проверяют только порт 22. Это уменьшает количество лишних записей в логах, но реальный злоумышленник просканирует все порты и все равно найдет сервис. Настоящую защиту от взлома обеспечивает аутентификация только по ключам. Если вы меняете порт, сначала откройте новый порт в firewall, затем выполните sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; в Ubuntu 24.04 слушатель управляется через socket, поэтому обычный reload оставит sshd на порту 22.

Нужен ли Fail2ban, если я использую SSH-ключи?

Это опционально, но все еще полезно. При аутентификации только по ключам подбор пароля невозможен, поэтому Fail2ban не является основным средством защиты от взлома. Он ограничивает количество попыток входа с одного адреса, что очищает логи от шума сканеров и блокирует нарушителей. Медленные распределенные атаки в любом случае остаются ниже порога блокировки. Используйте Fail2ban вместе с аутентификацией по ключам и, в идеале, держите SSH за VPN.

Что делать, если я заблокировал себе доступ по SSH?

Используйте веб-консоль вашего провайдера. Она обеспечивает доступ к серверу через serial или VNC соединение, которое не зависит от SSH. Через консоль вы сможете войти в систему, исправить drop-in файл sshd и перезагрузить службу. Именно поэтому необходимо проверять новый конфиг SSH в отдельном терминале перед закрытием текущей сессии, и именно поэтому аутентификация по ключам должна быть настроена до отключения паролей.