Защита свежего VPS: первичная настройка сервера Ubuntu за 10 минут

Свежий HIP-сервер с Ubuntu 24.04 поднимается с публичным IP и входом под root по паролю. Автоматические сканеры начинают стучаться в него в первые минуты после появления IP в сети - на нашем тестовом сервере счётчик неудачных попыток входа за несколько часов перевалил за 17 000. Эта первичная настройка закрывает базовые дыры примерно за десять минут: отдельный пользователь без root, вход только по ключу, отключённый пароль, файрвол и автоматические обновления безопасности. Все команды ниже выполнены на чистой Ubuntu 24.04.

Коротко. Заходим под root, заводим обычного пользователя с sudo, кладём ему свой SSH-ключ. Во втором терминале проверяем, что вход по ключу работает. Отключаем в sshd вход под root и по паролю, включаем ufw (сначала разрешив SSH) и unattended-upgrades. После этого sshd вообще не принимает парольную аутентификацию, и перебор пароля по SSH теряет смысл.

Что будет сделано

• Пользователь deploy с правами sudo - под ним вы работаете вместо root.
• Вход по SSH-ключу вместо пароля.
• В sshd запрещён вход под root и вход по паролю.
• Файрвол ufw: наружу открыт только порт 22.
• Автоматическая установка обновлений безопасности.

Шаг 0. Зайти под root

IP-адрес и пароль root - на странице сервера в панели, в блоке How to connect. Там же кнопка веб-консоли: она понадобится, если вы случайно закроете себе SSH. Если сервера ещё нет, создайте его по инструкции «Как создать сервер в панели HIP».

Подключаемся с вашего компьютера (Windows - PuTTY или встроенный ssh, macOS и Linux - ssh в терминале):

Шаг 1. Отдельный пользователь с sudo

Работать постоянно под root опасно: любая ошибка в команде выполняется с максимальными правами, а вход root по SSH - главная цель переборщиков. Заводим обычного пользователя и выдаём ему право повышать привилегии через sudo (по своему паролю).

Вывод id deploy должен показать группу sudo:

uid=1001(deploy) gid=1001(deploy) groups=1001(deploy),27(sudo)

adduser создаёт пользователя, домашний каталог и спрашивает пароль. Пароль нужен: под ним sudo будет переспрашивать подтверждение. В Ubuntu право на sudo даёт именно членство в одноимённой группе.

Шаг 2. Положить свой SSH-ключ пользователю

Ключ - пара файлов на вашем компьютере: закрытый остаётся у вас, открытый кладётся на сервер. Кто предъявил закрытый ключ, того сервер и пускает - пароль не нужен, а перебрать ключ нельзя. Если ключа ещё нет, создайте его на своём компьютере командой ssh-keygen -t ed25519; на сервер копируется файл .pub.

Рекомендуемые права - 700 на каталог .ssh и 600 на файл authorized_keys. Важно другое: каталог, файл и домашний каталог не должны быть доступны на запись посторонним - при небезопасном владельце или правах sshd с StrictModes может отказаться использовать ключ, и причина видна в логах sshd/journal.

Шаг 3. Проверить вход по ключу - во втором терминале

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

Шаг 4. Закрыть SSH: вход только по ключу

sshd - служба SSH на сервере. Её настройки не правят в основном файле, а кладут отдельным файлом в каталог /etc/ssh/sshd_config.d/ - так изменения переживут обновление пакета.

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

PermitRootLogin no - под root по SSH больше не зайти. PasswordAuthentication no - только ключ. sshd -t обязателен до перезагрузки службы: с битым конфигом sshd не поднимется, и вы останетесь снаружи.

Ловушка Ubuntu cloud-образа. После этого проверьте sshd -T | grep -i passwordauthentication - и, скорее всего, увидите yes. На облачных образах Ubuntu файл 50-cloud-init.conf в том же каталоге уже задаёт PasswordAuthentication yes, а sshd для таких параметров берёт первое найденное значение. Ваш файл 99-* читается позже и игнорируется. Решение - назвать файл так, чтобы он читался первым:

В выводе теперь должно быть permitrootlogin no, passwordauthentication no, kbdinteractiveauthentication no и maxauthtries 3.

Конфигурация применена - но текущую root-сессию пока не закрывайте. Откройте НОВОЕ SSH-соединение под deploy, убедитесь, что вход работает уже с применённым конфигом, и выполните sudo -v. Только когда это сработало, закрывайте старую root-сессию.

Шаг 5. Файрвол: наружу только SSH

ufw - простая обёртка над штатным файрволом Linux. Правило для SSH добавляем первым: если включить ufw с политикой «запретить входящие» и забыть про порт 22, текущая сессия оборвётся.

Профиль OpenSSH - это 22/tcp. Если вы перенесли SSH на другой порт, разрешайте этот порт явно (ufw allow 2222/tcp), а не профиль.

Профили веб-сервера (Nginx Full и подобные) добавляйте позже, когда поставите сам веб-сервер.

Шаг 6. Автообновления безопасности

Непропатченные известные уязвимости - один из основных рисков для публичного сервера. unattended-upgrades раз в сутки сам ставит обновления из security-репозитория.

На Ubuntu 24.04 unattended-upgrades обычно уже установлен и включён - проверьте, прежде чем что-то менять:

Активная служба и две строки со значением "1" означают, что всё включено. Если выключено:

В файле 20auto-upgrades две строки со значением "1" - обновление списка пакетов и установка обновлений включены. Перезагрузку после обновления ядра сервер по умолчанию не делает; при желании включается параметром Unattended-Upgrade::Automatic-Reboot.

Шаг 7. Финальная проверка

Вход под root по SSH должен отклоняться, а под новым пользователем по ключу - работать:

Что дальше

• fail2ban - банит IP после серии неудачных попыток. После выключенного пароля не критично, но снижает шум в логах.
• Снапшот. Сделайте снапшот сервера из панели прямо сейчас - чистая база, к которой можно откатиться.
• Обратная зона (PTR) - если сервер будет отправлять почту.

Если вы закрыли себе доступ

SSH - не единственный вход. В панели на странице сервера есть веб-консоль (VNC-консоль): она работает мимо sshd и файрвола, через неё вы попадёте на сервер под root по паролю и почините конфиг. Поэтому пароль root в панели стоит сохранить, даже когда вход по паролю в SSH выключен.

Вопросы и ответы

С чего начать настройку нового сервера Ubuntu?

С трёх вещей: отдельный пользователь с sudo, вход по SSH-ключу, отключение входа по паролю и под root в sshd. Дальше - файрвол ufw и автообновления. Это и есть базовая первичная настройка сервера; всё остальное зависит от задачи.

Обязательно ли отключать вход под root?

Удалённый вход по SSH сразу в привилегированную учётную запись не нужен для обычной работы. Отдельный пользователь плюс sudo оставляет повышение прав отдельным шагом и ограничивает то, что выполняется сразу с UID 0.

Почему PasswordAuthentication no не срабатывает на Ubuntu?

Потому что /etc/ssh/sshd_config.d/50-cloud-init.conf задаёт PasswordAuthentication yes и читается раньше вашего файла, а sshd берёт первое совпадение. Назовите свой файл 00-hardening.conf или отредактируйте 50-cloud-init.conf.

Я потерял закрытый ключ. Что делать?

Зайдите через веб-консоль в панели под root, добавьте в authorized_keys новый открытый ключ, при необходимости временно верните PasswordAuthentication yes.

Нужен ли ufw, если наружу и так смотрит только SSH?

Нужен. Сервисы имеют привычку появляться: поставили базу данных - и она уже слушает 0.0.0.0. С ufw такой порт не откроется наружу без вашего явного правила.

Коротко

• Не работайте под root - заведите пользователя с sudo.
• Ключ вместо пароля; вход по паролю и под root в sshd выключить.
• На Ubuntu cloud-образе назовите свой файл настроек 00-hardening.conf, иначе его перебьёт 50-cloud-init.conf.
• Правило для SSH в ufw - до включения файрвола.
• unattended-upgrades - чтобы известные дыры закрывались без вас.
• Веб-консоль в панели - запасной вход, если что-то сломали.