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

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

Вот короткая версия для тех, кто уже подключился к серверу и хочет сделать всё сразу. Подробности и объяснения ниже, по разделам.

1. Обнови систему: apt update && apt upgrade -y, при необходимости перезагрузись.
2. Создай пользователя и дай ему sudo: adduser deploy, затем usermod -aG sudo deploy.
3. Положи этому пользователю свой SSH-ключ.
4. Не закрывая текущее окно, открой второе и проверь вход под новым пользователем и работу sudo.
5. Только после этого запрети вход для root и по паролю, проверь конфиг и перезапусти SSH.
6. Разреши в файрволе SSH, 80 и 443 и лишь потом включи его.

Дальше по шагам. Команды рассчитаны на Ubuntu 24.04 и Debian 12–13, на остальных Debian-подобных системах всё почти так же.

Что выбрать ещё при заказе

Половина проблем решается до первого подключения. В панели провайдера почти всегда есть выбор ОС, и для первого сервера я бы брал Ubuntu 24.04 LTS или Debian: под них написано больше всего инструкций, и все команды из этой статьи на них проверяются без поправок. CentOS в списке может ещё попадаться, но эта ветка закрыта, обновлений безопасности для неё нет. Её выбирать не стоит, даже если старый мануал предлагает именно её.

Второе, что стоит сделать в форме заказа, – добавить свой публичный SSH-ключ, если такое поле есть. Тогда сервер с первой минуты пускает по ключу, а пароль root либо не создаётся вовсе, либо не нужен. Как сгенерировать ключ на своём компьютере, разобрано в статье про SSH-ключи вместо пароля.

Тип виртуализации тоже стоит посмотреть заранее. На KVM у тебя своё ядро и полная свобода, на OpenVZ часть вещей из этой статьи и из соседних (Docker, WireGuard, свой swap) может не заработать. Разница подробно описана в сравнении KVM и OpenVZ, а сами провайдеры собраны в рейтинге VPS.

Первое подключение и обновления

Провайдер присылает IP-адрес, логин (чаще всего root) и пароль, если ключ ты не добавлял. Подключение из терминала выглядит так:

ssh root@203.0.113.10

Вместо 203.0.113.10 подставь адрес своего сервера. На Windows 10 и 11 команда ssh встроена и работает в PowerShell, PuTTY для этого больше не обязателен. Все варианты, включая вопрос про «authenticity» при первом входе, собраны в статье как подключиться к VPS по SSH.

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

apt update
apt upgrade -y

Первая команда скачивает список доступных версий, вторая ставит обновления. Во время обновления могут выскочить два окна, на которых новички обычно замирают. Первое – вопрос про новую версию файла настроек, чаще всего /etc/ssh/sshd_config: провайдер поправил его при сборке образа, и система спрашивает, чей вариант оставить. Выбирай «keep the local version currently installed», то есть текущий. Второе, на Ubuntu, – розовое окно со списком служб, которые нужно перезапустить. Там достаточно нажать Enter.

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

ls /var/run/reboot-required
reboot

Через минуту подключайся снова. Заодно проверь, включены ли автоматические обновления безопасности. На Ubuntu пакет unattended-upgrades обычно уже стоит и работает, на Debian его часто нужно включить руками:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

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

Свой пользователь вместо root

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

adduser deploy
usermod -aG sudo deploy

Имя deploy здесь для примера, бери любое латиницей. adduser спросит пароль и несколько необязательных полей (имя, телефон), их можно пропустить Enter’ом. Пароль, в отличие от полей, не пропускай и запиши куда-нибудь. По SSH ты с ним заходить не будешь, но он нужен для sudo и, что важнее, для входа через аварийную консоль провайдера, если что-то пойдёт не так.

На минимальных образах Debian может не оказаться самого sudo. Тогда команда usermod ругнётся на несуществующую группу, и достаточно сначала выполнить apt install sudo.

SSH: сначала ключ и проверка, потом запреты

Этот раздел самый важный, и почти все истории «я потерял доступ к серверу» начинаются здесь. Обычно дело не в сложности, а в порядке: человек отключает вход по паролю, перезапускает SSH, закрывает окно – и только потом выясняет, что ключ новому пользователю так и не положил.

Положи ключ новому пользователю

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

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Если система ответит, что rsync не найден, поставь его через apt install rsync и повтори. Обычное копирование через cp здесь хуже: файлы останутся принадлежать root, и SSH не сможет прочитать их от имени нового пользователя.

Если ключа на сервере ещё нет, отправь его со своего компьютера. На Linux и macOS это делает ssh-copy-id:

ssh-copy-id deploy@203.0.113.10

На Windows ssh-copy-id нет, там ключ отправляется одной строкой PowerShell. Она целиком разобрана в статье про SSH-ключи, там же объяснено, что делать, если сервер ключ не принимает.

Проверь вход во втором окне

Текущую сессию под root не закрывай до конца настройки. Это твоя страховка: пока она открыта, любую ошибку можно исправить. Открой второй терминал и зайди новым пользователем:

ssh deploy@203.0.113.10
sudo whoami

Если вход прошёл без запроса пароля от SSH, а sudo whoami после ввода пароля пользователя ответил root, всё готово для следующего шага. Если SSH всё-таки спросил пароль, ключ не подхватился, и запрещать пароли пока рано.

Запрети root и пароли

Главный файл настроек SSH – /etc/ssh/sshd_config, но править его напрямую я не советую. В Ubuntu и Debian он в самом начале подключает файлы из папки /etc/ssh/sshd_config.d/, а SSH берёт первое встреченное значение каждого параметра. Отсюда неприятный сюрприз, который на клиентских серверах встречается постоянно: человек пишет PasswordAuthentication no в конец основного файла, а в логах продолжается перебор паролей. Причина – файл 50-cloud-init.conf в этой самой папке, который система создания образа положила с PasswordAuthentication yes. Он читается раньше и выигрывает.

Поэтому свои настройки удобнее держать в отдельном файле с именем, которое идёт по алфавиту раньше остальных:

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

Впиши в него две строки, ровно так, без точек и точек с запятой в конце:

PermitRootLogin no
PasswordAuthentication no

Сохрани файл (в nano это Ctrl+O, Enter, потом Ctrl+X) и проверь конфигурацию, прежде чем что-то перезапускать:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'

Первая команда при правильном конфиге не выводит ничего. Если она что-то пишет, там будет номер строки и описание ошибки, и перезапускать SSH нельзя, пока ошибка не исправлена. Вторая показывает значения, которые SSH реально применит, с учётом всех файлов. Там должно быть permitrootlogin no и passwordauthentication no. Если видишь yes, значит, какой-то другой файл перебивает твой.

Теперь перезапусти службу. В Ubuntu и Debian она называется ssh:

sudo systemctl restart ssh

И снова, не закрывая старые окна, открой третий терминал и зайди как deploy. Заодно попробуй ssh root@203.0.113.10: сервер должен ответить Permission denied. Только когда оба результата совпали с ожидаемыми, старые сессии можно закрывать.

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

sudo journalctl -u ssh --since today | grep -cE 'Failed|Invalid user'

На сервере, который прожил в интернете хотя бы сутки, число обычно трёхзначное, а иногда и четырёхзначное. Это не атака именно на тебя: боты идут по диапазонам адресов подряд и пробуют root, admin, test с паролями из словарей. Теперь, когда пароли отключены, эти попытки бессмысленны, они просто остаются в логе.

Менять ли порт 22

Многие инструкции советуют сразу перевести SSH на другой порт, например 2222. Честно о том, что это даёт: из логов пропадает основная масса ботов, которые долбятся в 22-й порт по всему интернету. От того, кто целенаправленно сканирует именно твой сервер, это не защищает, порт находится за минуты. Настоящую защиту дают ключ и запрет паролей, которые ты уже включил. Смена порта – приятное дополнение, не больше, и делать её лучше после того, как всё остальное проверено.

Если решил менять, порядок такой. Сначала открой новый порт в файрволе (о нём в следующем разделе), потом добавь в тот же файл 00-hardening.conf строку Port 2222 и снова проверь конфиг через sudo sshd -t.

Дальше есть отличие между системами. В Ubuntu, начиная с 22.10, SSH запускается через systemd-сокет, и простой перезапуск службы порт не меняет. Нужно так:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

На Debian достаточно обычного sudo systemctl restart ssh. В обоих случаях проверь, какой порт реально слушается, и подключись в новом окне с ключом -p:

sudo ss -tlnp | grep ssh
ssh -p 2222 deploy@203.0.113.10

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

Файрвол: сначала разрешить, потом включить

В Ubuntu уже есть UFW, простая надстройка над системным файрволом. По умолчанию он выключен. В Debian его сначала нужно поставить: sudo apt install ufw. Логика у него простая: входящие соединения запрещены, кроме тех, что ты разрешил явно, исходящие разрешены.

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

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

OpenSSH – это готовый профиль для стандартного 22-го порта. Если ты перенёс SSH на другой порт, вместо него пиши номер, например sudo ufw allow 2222/tcp, а старое правило убирай только после того, как проверил вход через новый порт. При ufw enable система предупредит, что может оборвать текущие SSH-соединения. Если SSH разрешён, ничего не оборвётся, соглашайся.

Одна ловушка, о которой узнают обычно слишком поздно: если позже поставишь Docker, опубликованные им порты открываются наружу в обход UFW. Контейнер с базой данных на -p 3306:3306 будет доступен из интернета, хотя ufw status покажет, что порт закрыт. Подробнее о правилах и о связке UFW с iptables – в статье про файрволы UFW и iptables, а про контейнеры – в статье про Docker на VPS.

Три мелочи, которые потом экономят время

Часовой пояс. На большинстве образов сервер живёт по UTC, и время в логах и расписании задач расходится с твоим на два-три часа. Искать в логе «что случилось в 14:05», зная, что там UTC, неудобно, поэтому лучше сразу выставить свой пояс:

sudo timedatectl set-timezone Europe/Kyiv

Имя сервера. Если серверов со временем станет два-три, приглашение вида root@ubuntu-s-1vcpu быстро начинает путать, в каком окне ты сейчас работаешь. Короткое понятное имя задаётся одной командой: sudo hostnamectl set-hostname web1.

Swap. На тарифах с 1–2 ГБ памяти его часто нет совсем, и это видно в выводе free -h в строке Swap. Пока на сервере только nginx, это незаметно. Но стоит поставить MySQL и WordPress, и в пиковый момент система начинает убивать процессы, чтобы освободить память. Со стороны это выглядит как «база иногда сама падает». Файл подкачки на 1–2 ГБ такие падения обычно снимает; как его создать и какой размер выбрать, разобрано в статье про swap-файл на VPS.

Проверка: Nginx и PHP на чистом сервере

Когда доступ защищён, можно ставить то, ради чего сервер брался. Для полноценного сайта с базой данных есть отдельные разборы LAMP/LEMP-стека и установки WordPress. Здесь только быстрая проверка, что веб-сервер и PHP поднимаются и видны снаружи.

sudo apt install nginx php-fpm -y
ls /run/php/

Вторая команда покажет сокет PHP-FPM с номером версии, например php8.3-fpm.sock на Ubuntu 24.04. Номер важен: он зависит от системы, и именно из-за него чаще всего не работают конфиги, скопированные из старых инструкций. Открой файл сайта по умолчанию:

sudo nano /etc/nginx/sites-available/default

Внутри блока server есть закомментированный кусок для PHP. Раскомментируй его так, чтобы получилось следующее, подставив свою версию из вывода ls:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Обрати внимание на обратный слэш перед точкой и на то, что строка fastcgi_pass должна остаться одна: в исходном файле их две, для сокета и для TCP. Проверь конфиг и примени его:

sudo nginx -t
sudo systemctl reload nginx

Теперь создай тестовый файл и открой в браузере http://203.0.113.10/info.php:

echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/info.php

Появилась большая таблица с версией PHP – всё работает. Если браузер вместо страницы предлагает скачать файл, блок location не раскомментирован или nginx не перечитал конфиг. Ошибка 502 почти всегда означает неверный номер версии в пути к сокету. После проверки удали файл сразу, он показывает любому посетителю пути, версии и настройки сервера:

sudo rm /var/www/html/info.php

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

Бывает. Выглядит нелогично, но потеря SSH почти никогда не означает потерю сервера. У большинства провайдеров в панели есть консоль (её называют VNC, KVM-консолью или просто Console), которая подключается к серверу как монитор с клавиатурой, минуя сеть и SSH. Запреты из 00-hardening.conf на неё не действуют, и файрвол тоже.

Войди туда своим пользователем по паролю, который задавал в adduser, и исправь ошибку: удали или поправь файл настроек SSH, либо разреши нужный порт через sudo ufw allow 22/tcp. Если консоли нет или пароль забыт, остаётся режим восстановления (rescue mode): сервер загружается с отдельной системы, и ты правишь файлы на своём диске как на флешке. Переустановка ОС – крайний вариант, она стирает всё.

Что дальше

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

Поставь Fail2ban, чтобы адреса, которые долбятся в SSH и в формы входа сайта, автоматически попадали в бан. Настрой резервное копирование в место за пределами сервера, пока там ещё нечего терять. И поставь хотя бы простой мониторинг нагрузки, чтобы узнавать о заполненном диске раньше посетителей. Общий список защитных мер собран в статье про безопасность VPS. Если работа в терминале всё-таки не твоё, посмотри на панели управления, но ставь их на свежий сервер, до того как настраивал что-то руками.

Источники

• sshd_config(5) – описание параметров SSH-сервера, OpenBSD
• OpenSSH server – Ubuntu Server documentation
• SSHd now uses socket-based activation (Ubuntu 22.10 and later) – Ubuntu Discourse
• Cannot disable PasswordAuthentication due to 50-cloud-init.conf – cloud-init, GitHub
• Automatic updates – Ubuntu Server documentation
• Firewalls (ufw) – Ubuntu Server documentation
• Packet filtering and firewalls – Docker Docs
• Module ngx_http_fastcgi_module – nginx documentation