Ошибки новичков при первом VPS: топ-15 по частоте

MAATRIX

Первый VPS почти всегда выглядит одинаково: вы получаете письмо с IP и паролем root, заходите по SSH — и дальше действуете интуитивно, потому что никто не объяснил, с чего начать. В результате сервер работает, но собран из десятка мелких упущений, которые через пару месяцев обернутся взломом, потерянными данными или тремя часами разбора «почему всё сломалось». Ниже — 15 конкретных ошибок именно первого захода на сервер, без теории: что делают неправильно и как сделать правильно за те же 10 минут.

Права доступа и пароли: фундамент, который пропускают

Три ошибки на старте закладывают проблемы на все время жизни сервера.

1. Работа постоянно под root. Хостер выдаёт доступ как root, и новичок так и работает — ставит пакеты, редактирует конфиги, запускает скрипты от имени суперпользователя без ограничений. Любая опечатка в команде (rm -rf не в той папке) или уязвимость в софте получает максимальные права в системе. Правильно — сразу создать обычного пользователя с sudo:

adduser deploy
usermod -aG sudo deploy
# на CentOS/AlmaLinux группа называется wheel:
usermod -aG wheel deploy

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

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

passwd root

Не «qwerty123», не название сервера, не дата рождения — генератор паролей и менеджер паролей, даже для тестового сервера. Боты сканируют весь интернет на 22-й порт и подбирают пароли по словарям круглосуточно, независимо от того, «важный» у вас сервер или учебный.

3. Не настраивают SSH-ключи, входят только по паролю. Пароль можно перебрать, подсмотреть, украсть через кейлоггер. Ключевая пара — практически неподбираемая аутентификация, и заодно избавляет от необходимости помнить пароль:

# на своей машине
ssh-keygen -t ed25519 -C "deploy@myserver"
ssh-copy-id deploy@server_ip

После проверки, что вход по ключу работает, отключите вход по паролю в /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

и перезапустите systemctl restart sshd. Практика показывает: если это не сделать в первый день, руки до этого не доходят месяцами. Пошаговая настройка — в статье про SSH-ключи вместо пароля.

Сеть открыта нараспашку

4. Не устанавливают firewall вообще. Свежий сервер часто раздаёт наружу больше, чем нужно: SSH, а иногда ещё и порты тестовых сервисов, баз данных, панелей администрирования, которые разработчик оставил открытыми «на время отладки». Без firewall всё это видно из интернета. Минимальная защита на Ubuntu/Debian — UFW:

ufw allow OpenSSH
ufw enable
ufw status verbose

На CentOS/AlmaLinux — firewalld:

firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

Дальше открывайте только то, что реально нужно снаружи (80/443 для веб-сервера, свой порт для приложения), а базы данных и внутренние сервисы держите закрытыми либо доступными только с localhost или через VPN. Как настроить UFW с нуля — в статье «firewall UFW на VPS».

14. Не проверяют, доступен ли сервер снаружи после настройки. Обратная ошибка того же корня: firewall настроили, всё «работает» — но проверяли только изнутри сервера (curl localhost) или из локальной сети, где правила фильтрации не срабатывают так, как со внешнего адреса. В итоге сайт недоступен для реальных посетителей, а разработчик понимает это только когда приходит первая жалоба. Проверяйте снаружи: с телефона на мобильном интернете, через сторонний сервис проверки портов, или просто curl -I http://ваш-ip с другой машины, не из локальной сети сервера. Это же касается firewall: правило, которое кажется верным на бумаге, иногда блокирует не то, что задумывалось — как избежать типовых промахов в правилах, разобрано в статье про ошибки в правилах firewall.

Заброшенная система сразу после установки

5. Не обновляют систему после первой установки. Образ, из которого разворачивается VPS, может быть собран несколько месяцев назад — за это время вышли патчи безопасности для ядра, OpenSSH, библиотек. Первая команда после входа на новый сервер должна быть:

# Debian/Ubuntu
apt update && apt upgrade -y

# CentOS/AlmaLinux
dnf update -y

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

6. Забывают часовой пояс и локаль. Мелочь, которая аукается позже: сервер по умолчанию часто живёт в UTC, а логи приложения, cron-задачи и расписание бэкапов ожидаются по вашему локальному времени. Когда через месяц нужно разобрать инцидент «что произошло в 21:40» — и оказывается, что в логах написано 18:40, — начинается путаница. Настройте сразу:

timedatectl set-timezone Europe/Moscow
# или нужный часовой пояс: timedatectl list-timezones
locale-gen ru_RU.UTF-8
update-locale LANG=ru_RU.UTF-8

Даже если приложение всё равно логирует в UTC — явно зафиксируйте это решение и держите его в одном месте, а не гадайте задним числом.

9. Не настраивают автоматические обновления безопасности. Разовое apt upgrade в день установки закрывает дыры на момент установки, но не на следующие месяцы. Новичок либо забывает обновлять сервер вручную, либо обновляет раз в полгода вместе с полной переустановкой. На Ubuntu/Debian есть unattended-upgrades, который тянет патчи безопасности автоматически:

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

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

Ресурсы и сторонний код без разбора

7. Не настраивают своп при малом объёме RAM. Бюджетные тарифы часто дают 1–2 ГБ RAM — этого хватает для небольшого сайта или бота, но при сборке пакетов, работе с базой данных под нагрузкой или неожиданном всплеске трафика память заканчивается, и процесс, который OOM-killer посчитает «лишним», убивается без предупреждения (часто это и оказывается ваше приложение или база). Своп не заменяет RAM по скорости, но даёт системе запас, чтобы не падать резко:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Размер свопа зависит от объёма RAM и задач — универсального числа тут нет, ориентируйтесь на объём вашей оперативной памяти и характер нагрузки. Подробный разбор настройки свопа — в материалах по настройке swap и производительности.

8. Ставят компоненты из непроверенных репозиториев и «curl | bash» не глядя. Установка одной командой вида curl https://example.com/install.sh | bash выглядит удобно, но вы выполняете от root (или через sudo) чужой скрипт, содержимое которого не видели и который может измениться на сервере автора между вашим первым и вторым запуском. То же касается сторонних .deb-репозиториев и PPA без понимания, кто их поддерживает. Минимальная гигиена: сначала скачать скрипт, открыть и прочитать, что он делает, и только потом выполнять:

curl -o install.sh https://example.com/install.sh
less install.sh
bash install.sh

Для системного софта предпочитайте официальные репозитории дистрибутива или официальные инструкции проекта с проверкой GPG-ключа репозитория, а не разовые шелл-скрипты со сторонних блогов.

13. Копируют команды с форумов, не понимая, что они делают. Частный случай той же проблемы: команда с форума решает похожую, но не идентичную проблему — например, меняет права на весь /etc вместо одного файла, или удаляет содержимое директории, которая на вашем сервере используется по-другому. Если не понимаете, что делает флаг команды — сначала посмотрите man или официальную документацию, выполните на тестовом сервере, и только потом на боевом. Особенно осторожно с командами, содержащими rm -rf, chmod -R 777, dd, перенаправление в системные файлы конфигурации.

Один сервер на всё и без страховки

10. Держат тестовые проекты и важное на одном сервере без разделения. Учебный Node.js-проект, тестовая база данных и рабочий сайт клиента живут на одном VPS «пока не появится второй сервер». Ошибка в тестовом коде (утечка памяти, бесконечный цикл, случайный DDoS на себя же) кладёт вместе с ним и то, что действительно важно. Даже на одном физическом сервере разделяйте окружения хотя бы логически: отдельные системные пользователи, отдельные базы данных, контейнеры (Docker) с ограничением ресурсов через --memory и --cpus, а для по-настоящему разных задач — отдельные VPS, благо стоимость младших тарифов невелика по сравнению со стоимостью простоя рабочего проекта.

11. Не настраивают бэкапы с первого дня. Классика: «настрою бэкапы, когда будет что бэкапить». К моменту, когда на сервере появляются реальные данные, про эту мысль уже забыли — а первый серьёзный сбой случается именно тогда, когда терять уже есть что. Минимальная настройка занимает 15 минут:

# простой пример: ежедневный дамп базы + ротация через cron
0 3 * * * pg_dump mydb | gzip > /backups/mydb-$(date +\%F).sql.gz
0 4 * * * find /backups -mtime +7 -delete

Для серьёзной работы стоит сразу смотреть в сторону инструментов с версионированием и дедупликацией, например BorgBackup, и обязательно хранить копию не на том же диске, где лежат исходные данные — иначе при отказе диска вы теряете и данные, и их резервную копию одновременно. Разбор частых ошибок в такой настройке — в статье про бэкапы баз данных.

Паника при первой ошибке и отсутствие документации

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

journalctl -u имя-сервиса -n 100 --no-pager
systemctl status имя-сервиса
tail -n 100 /var/log/syslog

В подавляющем большинстве случаев причина — в этих логах текстом, а не «сервер сломался необъяснимо».

15. Не документируют, что и как настроили. Через месяц-два вы не вспомните, зачем открыт порт 8081, какой пользователь имеет доступ к базе и почему в конфиге nginx закомментирован один блок. Документация не обязана быть длинной — достаточно текстового файла в репозитории или заметки рядом с проектом: какие порты открыты и зачем, какие пользователи и роли созданы, какие нестандартные решения приняты и почему. Это экономит часы при следующей настройке похожего сервера и спасает, когда к проекту подключается кто-то ещё, кроме вас. Общий порядок действий в первый день на сервере, который стоит зафиксировать себе за правило, собран в чек-листе первого дня на VPS.

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