Как настроить безопасный SSH на VPS

Почему SSH — это первое, что нужно защитить

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

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

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

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

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

ssh-keygen -t ed25519

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

ssh-copy-id user@your-server

Затем откройте новую SSH-сессию. Если вход выполняется без запроса пароля, значит, ключ работает и можно безопасно отключать пароли. Если система выдает ошибку Permission denied (publickey), эта ошибка может скрывать пять различных проблем, и вывод ssh -v укажет на конкретную причину, прежде чем вы начнете вносить другие изменения. Если вы впервые работаете с ключами или используете несколько компьютеров, основы управления 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 — самая важная настройка: при отключении паролей брутфорс-атака становится бессмысленной. KbdInteractiveAuthentication no закрывает еще один путь для аутентификации по паролю. PermitRootLogin no означает, что злоумышленнику потребуется знать ваше имя пользователя и обладать ключом, а не просто пытаться подобрать пароль к учетной записи root, которая существует на любом сервере.

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

Перед применением настроек проверьте конфигурацию на наличие ошибок, чтобы опечатка не привела к остановке сервиса:

sudo sshd -t

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

sudo systemctl reload ssh

Затем проверьте настройки, которые фактически использует sshd, чтобы убедиться, что параметры из drop-in файлов не были переопределены:

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

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

Шаг 4: Использование нестандартного порта (опционально)

Перенос SSH с порта 22 на другой, например 2222, не повышает безопасность в реальном смысле, так как целеустремленный злоумышленник просканирует все порты. Это лишь снижает количество записей в логах, поскольку большинство автоматизированных сканеров проверяют только порт 22. Если вы хотите это сделать, добавьте Port 2222 в свой drop-in файл, сначала разрешите новый порт в межсетевом экране, затем выполните 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 за VPN-туннелем WireGuard и закроете 22 порт в файрволе для внешних подключений, никто вне VPN не сможет даже обратиться к службе. Брутфорс станет не просто сложным, а невозможным. Все эти меры предполагают использование файрвола с политикой запрета по умолчанию, как описано в настройке UFW на VPS.

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

FAQ

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

Создайте файл конфигурации в /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. Перед тем как полагаться на этот метод, убедитесь в новой сессии, что вход по ключу работает. Редактирование отдельного файла вместо sshd_config позволяет сохранить настройки при обновлении пакетов и упрощает отмену изменений.

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

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

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

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

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

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

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

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