Настройка VPS с нуля: пошаговое руководство по Ubuntu

Вы арендовали сервер и получили письмо с IP-адресом и паролем root. Что дальше? Сервер в этот момент открыт всему интернету, и боты начнут перебирать пароль к нему в течение первых же минут. Это не преувеличение: типичный VPS ловит сотни попыток входа в сутки.

Эта инструкция закрывает базовую настройку VPS: от первого подключения до состояния, когда сервером можно пользоваться спокойно. Все команды приведены для Ubuntu 24.04 LTS, но подойдут и для Ubuntu 22.04 и Debian 12 с минимальными правками.

Времени займёт: около 30 минут.

Что нужно перед стартом

Шаг 1. Подключение по SSH

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

Подключаемся:

ssh root@203.0.113.10

При первом подключении система спросит про отпечаток ключа сервера. Это нормально: так SSH запоминает сервер, чтобы в будущем распознать подмену. Отвечаем yes и вводим пароль.

The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:qP8f2mK...
Are you sure you want to continue connecting (yes/no)? yes

Если видите приглашение вида root@server:~# - вы внутри.

⚠️ Ошибка "Permission denied"? Проверьте раскладку и то, что копируете пароль без пробела в конце. Если провайдер выдал SSH-ключ вместо пароля, подключайтесь так: ssh -i ~/.ssh/имя_ключа root@ВАШ_IP

Шаг 2. Обновление системы

Первое, что делаем на новом сервере, - ставим свежие пакеты. В образе они почти всегда отстают на недели или месяцы, а среди обновлений бывают закрытые уязвимости.

apt update && apt upgrade -y

Команда apt update обновляет список доступных пакетов, apt upgrade - сами пакеты. Если система попросит перезагрузку, не откладывайте:

reboot

Через минуту подключитесь заново.

Шаг 3. Пользователь с sudo вместо root

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

Создаём обычного пользователя:

adduser mike

Система попросит пароль и несколько необязательных полей - их можно пропустить, нажимая Enter.

Теперь выдаём права администратора:

usermod -aG sudo mike

Проверяем, что всё работает. Открываем новую вкладку терминала (старую пока не закрывайте, это страховка) и подключаемся под новым пользователем:

ssh mike@203.0.113.10
sudo whoami

Если в ответ пришло root - права есть, идём дальше. Дальше все команды выполняем через sudo.

Шаг 4. SSH-ключи вместо пароля

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

Генерируем ключ на своём компьютере, не на сервере:

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

На вопрос про путь нажмите Enter. Пароль на ключ (passphrase) задавать не обязательно, но с ним безопаснее: если ноутбук украдут, ключом не воспользуются.

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

ssh-copy-id mike@203.0.113.10

Если ssh-copy-id нет (бывает на Windows), сделайте вручную:

cat ~/.ssh/id_ed25519.pub | ssh mike@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Проверяем: ssh mike@203.0.113.10 должен пустить без пароля.

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

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

⚠️ Важно. Не закрывайте текущую сессию, пока не проверите новую. Иначе рискуете закрыть себе доступ к серверу.

Открываем конфиг SSH:

sudo nano /etc/ssh/sshd_config

Находим и приводим к такому виду:

Сохраняем (Ctrl+O, Enter, Ctrl+X) и применяем:

sudo systemctl restart ssh

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

Шаг 6. Файрвол ufw

Файрвол закрывает все порты, кроме тех, что вы явно открыли. Даже если на сервере случайно поднимется служба с уязвимостью, снаружи до неё не достучатся.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

⚠️ Сначала allow OpenSSH, потом enable. Если включить файрвол, не разрешив SSH, вы потеряете доступ к серверу.

Типовые порты, которые открывают по мере надобности:

Проверить статус:

sudo ufw status verbose

Правило простое: открывайте только то, что действительно используется снаружи. Базы данных и внутренние сервисы наружу выставлять не нужно.

Шаг 7. Fail2ban против перебора

Даже с ключами в логах будут тысячи попыток входа. Fail2ban читает логи и банит IP, который повторяет неудачные попытки.

sudo apt install fail2ban -y

Создаём свой конфиг (штатный jail.conf перезаписывается при обновлениях, поэтому правим копию):

sudo nano /etc/fail2ban/jail.local

Содержимое:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true

Что это значит: 5 неудачных попыток за 10 минут - бан на час.

Запускаем:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Через сутки загляните в статус ещё раз - увидите список забаненных адресов.

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

Обновления безопасности выходят регулярно, а руками их ставят редко. Пусть ставятся сами.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Выбираем "Yes". Проверить, что механизм работает:

sudo unattended-upgrades --dry-run --debug

Так закрываются только security-обновления. Мажорные версии пакетов сами не поедут, и это правильно: неожиданное обновление в проде опаснее, чем его отсутствие.

Итоговый чек-лист

Если все семь пунктов отмечены - базовая настройка закончена. Сервер готов к тому, чтобы разворачивать на нём проект.

Частые ошибки

Включили ufw до allow OpenSSH. Доступ потерян. Лечится только через консоль в панели управления - она работает в обход сети.

Отключили пароль, не проверив ключ. Та же история. Всегда держите вторую открытую сессию, пока не убедились, что новый способ входа работает.

Сгенерировали ключ на сервере, а не на своём компьютере. Тогда закрытая часть лежит на сервере, и весь смысл теряется. Ключ генерируется там, откуда вы подключаетесь.

Открыли порт базы данных наружу. Очень частая причина утечек. Если БД и приложение на одном сервере, порт наружу не нужен вообще.

Что дальше

Базовый сервер готов. Дальше обычно идут:

• установка Docker, если проект в контейнерах;
• веб-сервер Nginx и SSL-сертификат;
• панель управления, если не хочется работать через консоль;
• мониторинг и резервное копирование.

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

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

Что делать, если потерял доступ к серверу? Используйте консоль в панели управления: она подключается к серверу напрямую, минуя SSH и файрвол. Через неё можно откатить правки конфига.

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

Подойдёт ли инструкция для Debian? Да, все команды работают на Debian 12 без изменений. На CentOS и AlmaLinux вместо apt будет dnf, а вместо ufw - firewalld.

Сколько ресурсов нужно для такой настройки? Сама настройка ресурсов почти не требует: хватит 1 vCPU и 1 ГБ RAM. Требования определяет проект, который вы будете разворачивать.

Разворачиваете проект с нуля? VPS на NVMe в дата-центрах Tier III в России и Европе. Активация за 3 минуты, Ubuntu и Debian из коробки, root-доступ сразу. Первые 7 дней - тестовый период с возвратом средств.