Пять шагов, которые стоит сделать до того, как вы поставите на новый VPS хоть что-то ещё: обновить систему, завести отдельного пользователя с sudo, перейти на вход по ключу, закрыть root по паролю через sshd_config.d и включить ufw, не заблокировав себе доступ.

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

Коротко. Подключитесь по SSH под root, выполните apt update && apt upgrade -y. Создайте обычного пользователя через adduser, добавьте его в группу sudo. Сгенерируйте на своём компьютере ключ ssh-keygen -t ed25519 и скопируйте его этому пользователю через ssh-copy-id. Убедитесь, что вход по ключу работает - и только после этого создайте файл /etc/ssh/sshd_config.d/10-hardening.conf с PermitRootLogin prohibit-password и PasswordAuthentication no, проверьте его командой sshd -t и примените через systemctl reload ssh. В конце - ufw allow OpenSSH и только потом ufw enable: порядок именно такой, иначе рискуете остаться без доступа.

Почему root работает сразу, и почему это стоит поменять

На новом сервере от WeaselCloud панель показывает ssh root@IP и пароль как основной способ подключиться - это сделано осознанно, чтобы вы могли зайти сразу, без настройки перед первым входом. Но у пароля есть цена: его можно подобрать перебором, а по IP-адресам серверов такие попытки идут почти постоянно, ботами, перебирающими диапазоны хостинг-провайдеров. Чем дольше root доступен по паролю, тем выше шанс, что однажды подберут именно ваш. Дальше мы закрываем этот вход - не «прячем» root, а даём себе нормальный путь внутрь: отдельного пользователя и ключ, который перебором не подобрать. Чем root отличается от sudo - подробно в статье root, su и sudo в Ubuntu; здесь берём это как данность и переходим к действиям.

Шаг 1. Обновите систему

Подключитесь к серверу по SSH под root (если ещё не подключались - помогут инструкции для Windows и для macOS и Linux). Обновите список пакетов и сами пакеты:

apt update && apt upgrade -y

apt update обновляет список доступных версий пакетов из репозиториев, apt upgrade -y ставит обновления, включая патчи безопасности, без вопросов по каждому пакету. Образ сервера мог быть собран заранее, а за это время выйти критичные обновления - в том числе для самой службы SSH.

В конце иногда появляется сообщение о перезапуске нескольких служб - это ожидаемо, apt сам перезапускает то, что затронули обновления, и текущая SSH-сессия не обрывается. Если появился файл /var/run/reboot-required, сервер стоит перезагрузить, но не обязательно прямо сейчас.

Шаг 2. Создайте пользователя с правами sudo

Работать под root напрямую - плохая привычка: одна опечатка в команде вроде rm -rf с лишним пробелом обходится дороже, если у вас нет никаких ограничений. Создайте обычного пользователя:

adduser deploy

Замените deploy на любое имя. Команда спросит пароль (введите свой, он потребуется для sudo) и необязательные данные вроде полного имени - их можно пропустить клавишей Enter. Добавьте пользователя в группу sudo, которая даёт право выполнять команды от root:

usermod -aG sudo deploy

-a значит «добавить», не заменяя существующие группы пользователя, -G sudo - в какую группу добавить. Важная деталь: когда вы наберёте sudo под этим пользователем, система спросит пароль именно deploy, заданный на шаге выше, а не пароль root из панели.

Шаг 3. Настройте вход по ключу для нового пользователя

Пароль, даже свой собственный, можно перебрать или потерять в переписке. Ключ решает обе проблемы: приватная часть остаётся только на вашем компьютере, а сервер пускает того, кто докажет владение парным ключом. На своём компьютере (не на сервере) создайте пару ключей:

ssh-keygen -t ed25519 -C "you@laptop"

На вопрос про расположение файла нажмите Enter. Скопируйте публичный ключ новому пользователю на сервер:

ssh-copy-id deploy@IP-адрес-сервера

Команда спросит пароль deploy (последний раз), создаст каталог ~/.ssh у этого пользователя и допишет ваш публичный ключ в ~/.ssh/authorized_keys с правильными правами. Если ssh-copy-id недоступен, ручной способ и разбор ошибок вроде Permission denied подробно разобраны в статье про подключение по SSH из macOS и Linux - тот же принцип, только для другого пользователя вместо root.

Проверка - самый важный момент этого шага. Откройте новое окно терминала, не закрывая текущую сессию под root, и подключитесь под новым пользователем:

ssh deploy@IP-адрес-сервера

Если сервер пустил без запроса пароля (или спросил только passphrase от файла ключа) - ключ работает, можно двигаться дальше. Если нет - чините сейчас, пока открыта сессия под root: следующий шаг закрывает вход по паролю, и если ключ на самом деле не работает, вы останетесь без доступа к серверу вообще.

До первых 10 минут

После

Вход по SSH

root, по паролю, с любого IP

отдельный пользователь, только по ключу

Root по SSH

доступен с паролем

вход по паролю закрыт, доступен только по ключу, если вообще нужен

Открытые порты

всё, что слушает система, доступно снаружи

только порт SSH и то, что вы явно разрешили в ufw

Шаг 4. Отключите вход root по паролю

Настройки SSH задаются файлом /etc/ssh/sshd_config, но редактировать его напрямую - плохая идея: при обновлениях системы файл может быть перезаписан, и правки потеряются. Вместо этого используется каталог /etc/ssh/sshd_config.d/ - любой файл .conf в нём подключается автоматически и переживает обновления. Создайте свой:

cat > /etc/ssh/sshd_config.d/10-hardening.conf << 'EOF'
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
EOF

PermitRootLogin prohibit-password - root по-прежнему может зайти по SSH-ключу (иногда нужно для резервного копирования), но не по паролю; чтобы закрыть root по SSH полностью, замените на no - тогда не пустит даже по ключу, только через веб-консоль в панели. PasswordAuthentication no закрывает вход по паролю для всех, не только для root, - иначе пароль пользователя из шага 2 остался бы такой же мишенью. PubkeyAuthentication yes явно включает вход по ключу, хотя он обычно включён и по умолчанию.

Тонкость с именем файла. Файлы в sshd_config.d/ подключаются по алфавиту, и для одного параметра побеждает первое встреченное значение - более поздние повторения молча игнорируются. На части образов Ubuntu уже есть файл вроде 50-cloud-init.conf, включающий вход по паролю. Назовите свой 90-hardening.conf - он загрузится позже, и запрет попросту не сработает, хотя будет выглядеть правильным. Поэтому имя начинается с 10-: меньше 50, чтобы гарантированно побеждать.

Перед перезапуском проверьте синтаксис - при успехе команда молчит и завершается без ошибки, при опечатке покажет строку с проблемой:

sshd -t

Дальше примените изменения без разрыва текущих подключений:

systemctl reload ssh

На Ubuntu 24.04 служба называется ssh, не sshd - так называется юнит systemd, хотя сама программа по-прежнему sshd. reload, в отличие от restart, перечитывает конфигурацию без обрыва открытых сессий, включая вашу текущую.

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

Шаг 5. Включите ufw - в правильном порядке

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

ufw allow OpenSSH

OpenSSH - готовый профиль, который добавляет правило сразу для IPv4 и IPv6 на порту, где слушает SSH (по умолчанию 22). Если SSH перенесён на нестандартный порт, замените на ufw allow <номер порта>/tcp. Только теперь включайте фаервол:

ufw enable

Команда переспросит подтверждение примерно такими словами: «Command may disrupt existing ssh connections. Proceed with operation (y|n)?» - это не сбой, а встроенное предупреждение именно про тот случай, которого мы избежали, разрешив SSH заранее. Отвечайте y. Проверьте итоговый список правил:

ufw status

В выводе должна быть строка со статусом active и разрешённым SSH. Если позже понадобится открыть порт для сайта или другого сервиса - та же команда с нужным портом, например ufw allow 80/tcp.

Если что-то пошло не так

Потеряли SSH-доступ - например, закрыли пароль до того, как убедились, что ключ работает? Сервер продолжает работать, недоступен только вход по SSH. В личном кабинете у сервера есть веб-консоль - доступ к командной строке через браузер, минуя SSH и любые правила ufw. Через неё можно зайти и поправить сломанное: вернуть настройку в sshd_config.d, донастроить authorized_keys или временно отключить фаервол командой ufw disable.

Частые вопросы

Что сделать сразу после покупки VPS

Обновить систему, создать пользователя с sudo и вход по ключу, отключить пароль root через sshd_config.d и включить ufw, разрешив SSH до включения. Это и есть первые 10 минут из этой статьи - делать что-то ещё до этих пяти шагов не стоит.

Как отключить вход root по паролю по SSH

Файл /etc/ssh/sshd_config.d/10-hardening.conf со строками PermitRootLogin prohibit-password и PasswordAuthentication no, проверка sshd -t, применение systemctl reload ssh. Делайте это только после того, как убедились, что вход по ключу под другим пользователем работает.

Как создать пользователя с правами sudo в Linux

adduser имя_пользователя создаёт пользователя и задаёт пароль, usermod -aG sudo имя_пользователя добавляет его в группу sudo, которая даёт право выполнять команды от root через sudo команда. Пароль для sudo - тот, что задан при создании пользователя, не пароль root.

Почему ufw заблокировал SSH после enable

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

Нужно ли менять пароль root на новом сервере

Да, даже если вы полностью закрываете вход root по паролю через SSH: первичный пароль побывал в панели и в письме открытым текстом, а сам пароль может понадобиться для веб-консоли, где ограничения SSH не действуют. Подробности - в статье смена пароля в Ubuntu.

Коротко

  • Первые 10 минут после получения доступов к VPS - обновление системы, отдельный пользователь с sudo, вход по ключу, отключение пароля root и ufw, именно в этом порядке.
  • apt update && apt upgrade -y - обновить пакеты, включая патчи безопасности, прежде чем ставить что-либо ещё.
  • adduser deploy и usermod -aG sudo deploy - отдельный пользователь вместо постоянной работы под root.
  • ssh-keygen на своём компьютере, ssh-copy-id на сервер - и обязательно проверить вход по ключу в новом окне, не закрывая старую сессию.
  • Отключать пароль root - только через /etc/ssh/sshd_config.d/, файлом с номером ниже 50, чтобы не проиграть по порядку загрузки другим файлам в этом каталоге.
  • sshd -t для проверки синтаксиса, systemctl reload ssh для применения без разрыва сессии.
  • ufw allow OpenSSH строго до ufw enable - иначе первое включение фаервола отрежет вам доступ.
  • Заблокировали сами себя - веб-консоль в личном кабинете работает в обход SSH и ufw.

Что дальше