Первичная настройка Ubuntu VPS после заказа: SSH, обновления, firewall и резервное копирование

После заказа Ubuntu VPS провайдер обычно передает IP-адрес сервера и данные для первого подключения. Технически этого достаточно, чтобы войти по SSH и начать устанавливать приложения. Но сервер с настройками по умолчанию еще не готов к нормальной эксплуатации.

На новом VPS часто доступна только учетная запись root, не настроен отдельный администратор, не проверены обновления, а локальный firewall либо выключен, либо не содержит правил для будущих сервисов. Также остается открытым вопрос резервного копирования: снимок виртуальной машины, копия файлов и резервная копия базы данных решают разные задачи и не заменяют друг друга.

Ошибки на этом этапе обычно проявляются позже. Администратор может заблокировать себе SSH-доступ после включения firewall, потерять сервер из-за неверной правки конфигурации SSH или обнаружить после сбоя, что резервная копия хранилась на том же VPS.

Ниже приведен безопасный базовый порядок настройки Ubuntu VPS. Команды подходят для актуальных серверных выпусков Ubuntu, однако перед выполнением их нужно сопоставить с версией системы, сетевой схемой и требованиями размещаемого приложения.

Что проверить перед изменением настроек

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

Для подключения из Linux, macOS или современной Windows используется клиент SSH:

ssh root@203.0.113.10

Замените 203.0.113.10 на фактический IP-адрес VPS. Если провайдер создал другого пользователя, укажите его имя вместо root.

При первом подключении SSH показывает fingerprint ключа сервера. Его желательно сверить со значением в панели провайдера или получить через доверенный канал. Простое подтверждение неизвестного fingerprint лишает проверку смысла: клиент запоминает ключ, но не подтверждает, что соединение установлено именно с нужным сервером.

После входа нужно зафиксировать основные сведения о системе:

hostnamectl
cat /etc/os-release
uname -r
ip address
ip route
df -h
free -h

Эти команды позволяют проверить:

• версию Ubuntu и ядра;
• имя сервера;
• сетевые интерфейсы и назначенные адреса;
• маршрут по умолчанию;
• размер и заполнение файловых систем;
• объем оперативной памяти и swap.

Также следует проверить текущее время и синхронизацию:

timedatectl

Неверное время приводит к ошибкам проверки TLS-сертификатов, журналирования, аутентификации и выполнения заданий по расписанию.

Исходный чек-лист VPS

Создание отдельного администратора

Постоянная работа под root неудобна и увеличивает последствия случайной ошибки. Для административных задач лучше создать отдельного пользователя и выдавать повышенные полномочия через sudo.

Создание пользователя:

adduser adminuser

Вместо adminuser укажите собственное имя. Команда запросит пароль и дополнительные данные. Поля с необязательной информацией можно оставить пустыми.

Затем пользователя добавляют в группу sudo:

usermod -aG sudo adminuser

Проверить состав групп можно командой:

id adminuser

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

ssh adminuser@203.0.113.10

Проверка sudo:

sudo whoami

Ожидаемый результат:

root

Настройка входа по SSH-ключу

Для регулярного администрирования удобнее использовать ключи SSH. Закрытый ключ хранится на рабочем компьютере администратора, а открытый размещается на сервере.

Если ключа еще нет, его можно создать на рабочей станции:

ssh-keygen -t ed25519

Во время создания рекомендуется задать парольную фразу. Она защищает закрытый ключ, если файл будет скопирован посторонним лицом.

Передать открытый ключ на сервер можно командой:

ssh-copy-id adminuser@203.0.113.10

Если ssh-copy-id недоступен, содержимое файла с расширением .pub добавляют в:

/home/adminuser/.ssh/authorized_keys

Права должны разрешать чтение каталога и файла только владельцу:

chmod 700 /home/adminuser/.ssh
chmod 600 /home/adminuser/.ssh/authorized_keys
chown -R adminuser:adminuser /home/adminuser/.ssh

После этого снова выполняется вход в отдельном терминале:

ssh adminuser@203.0.113.10

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

Обновление системы и установка базовых пакетов

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

sudo apt update
sudo apt upgrade

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

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

Узнать, требуется ли перезагрузка, можно так:

test -f /var/run/reboot-required && cat /var/run/reboot-required

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

sudo reboot

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

Какие пакеты могут понадобиться

Набор инструментов зависит от задач сервера. Для базовой диагностики часто устанавливают:

sudo apt install curl wget vim git unzip htop

Не следует устанавливать большой набор пакетов только «на будущее». Каждый дополнительный сервис требует обновлений и может создавать новые сетевые точки входа.

Автоматическая установка обновлений безопасности

В Ubuntu для автоматической установки исправлений используется пакет unattended-upgrades.

sudo apt install unattended-upgrades

Проверить конфигурацию можно командой:

sudo unattended-upgrade --dry-run --debug

Тестовый запуск не должен заменять просмотр настроек. Нужно определить:

• какие репозитории разрешено обновлять автоматически;
• нужна ли автоматическая перезагрузка;
• в какое время допустима перезагрузка;
• куда отправлять уведомления об ошибках;
• как обновления согласуются с работой приложений.

Настройка SSH и firewall без потери доступа

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

Упрощенная схема выглядит так:

         Рабочая станция администратора
                       │
                       │ SSH
                       ▼
              Сетевой firewall
             или правила провайдера
                       │
                       ▼
                  UFW на VPS
                       │
                       ▼
                 OpenSSH Server
                       │
                       ▼
            Учетная запись с sudo

Проверка конфигурации OpenSSH

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

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

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

/etc/ssh/sshd_config.d/

Эффективные параметры можно посмотреть командой:

sudo sshd -T

После изменения конфигурации необходимо проверить синтаксис:

sudo sshd -t

Если команда не выводит ошибок, конфигурацию можно применить:

sudo systemctl reload ssh

Перезапускать службу без проверки синтаксиса не следует. Ошибка в конфигурации может остановить SSH и заблокировать новый вход.

Ограничение прямого входа root

После проверки отдельного администратора и ключа можно ограничить прямой удаленный вход root. Конкретная политика зависит от способа аварийного доступа и требований организации.

Для запрета входа root по SSH используется параметр:

PermitRootLogin no

Для отключения парольной аутентификации:

PasswordAuthentication no

Отключать парольный вход можно только после того, как:

• ключ нового пользователя проверен;
• sudo работает;
• открыт второй активный SSH-сеанс;
• доступна консоль VPS в панели провайдера;
• ключ сохранен в надежном месте.

Настройка UFW

UFW используется как интерфейс управления локальным firewall Ubuntu. До его включения нужно разрешить используемый SSH-порт.

Посмотреть текущее состояние:

sudo ufw status verbose

Если SSH работает на стандартном порту, разрешить профиль OpenSSH можно так:

sudo ufw allow OpenSSH

Либо явно разрешить порт:

sudo ufw allow 22/tcp

Если SSH переведен на другой порт, в правиле указывается фактическое значение. После добавления разрешения firewall включается командой:

sudo ufw enable

Затем нужно проверить правила:

sudo ufw status numbered

Не закрывая текущий сеанс, следует выполнить новое подключение к серверу. Только после успешной проверки можно продолжать настройку.

Проверка служб, журналов и состояния VPS

После создания пользователя, обновления и настройки firewall нужно проверить, какие службы запущены и какие порты слушает сервер.

Неуспешные службы:

systemctl --failed

Активные сетевые сокеты:

sudo ss -tulpn

Команда показывает адрес, порт и процесс, который принимает соединения. Это помогает найти сервисы, которые были запущены образом провайдера или установлены вместе с зависимостями.

Последние системные ошибки:

sudo journalctl -p warning -b

Журнал службы SSH:

sudo journalctl -u ssh --since today

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

Проверка ресурсов

Для базового контроля используются:

uptime
free -h
df -h
df -i
top

df -h показывает заполнение диска по объему, а df -i — использование inode. Файловая система может перестать создавать новые файлы даже при наличии свободного места, если исчерпаны inode.

Также полезно проверить размер журналов:

journalctl --disk-usage

Если приложение активно записывает логи, нужно заранее настроить их ротацию и контроль свободного места.

Имя сервера и DNS

Понятное имя упрощает сопровождение нескольких VPS. Изменить hostname можно командой:

sudo hostnamectl set-hostname app01.example.local

Фактическое имя нужно выбирать в соответствии с принятой схемой именования. После изменения проверяются файлы /etc/hostname и /etc/hosts, а также разрешение DNS, если сервер должен быть доступен по доменному имени.

Резервное копирование и проверка восстановления

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

Снимок VPS, копия файлов и резервная копия базы данных имеют разные свойства:

Для рабочего сервера обычно требуется сочетание нескольких способов. Например:

• периодический снимок перед крупными изменениями;
• регулярное копирование конфигурации и пользовательских файлов;
• отдельный backup базы данных;
• копия за пределами самого VPS;
• проверка восстановления.

Какие данные сохранить сразу

До установки приложения полезно зафиксировать и сохранить вне VPS:

• версию Ubuntu;
• перечень установленных пакетов;
• конфигурацию SSH;
• правила UFW;
• сетевые параметры;
• список пользователей и групп;
• расписание задач;
• описание дисков и точек монтирования.

Список пакетов можно получить командой:

dpkg-query -W -f='${binary:Package}\t${Version}\n' > packages.txt

Правила UFW:

sudo ufw status numbered

Это не заменяет резервную копию, но ускоряет восстановление конфигурации на новом сервере.

Проверка восстановления

Наличие успешно созданного архива еще не подтверждает, что данные можно восстановить. Проверка должна включать как минимум:

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

Заключение

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

Изменения безопасности следует выполнять поэтапно. Новый пользователь, SSH-ключ и правило firewall сначала проверяются в отдельном сеансе. Только после этого можно ограничивать прямой доступ root и отключать парольную аутентификацию.

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

Что почитать дальше

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

• Безопасность Linux VPS: как защитить сервер и сайты — какие уровни защиты нужны после первичной настройки сервера.
• BitNinja: многоуровневая защита Linux-сервера — как работает дополнительная защита от вредоносных файлов, атак и подозрительной активности.
• Fastpanel или ispmanager — чем отличаются панели управления и в каких случаях они нужны на VPS.
• Бесплатный SSL-сертификат для сайта — когда подходит бесплатный сертификат и что учитывать при настройке HTTPS.

Когда стоит обратиться к специалистам

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

Если сервер еще не заказан или текущих ресурсов недостаточно для размещаемого приложения, можно подобрать VPS на Ubuntu с подходящим объемом процессорных ресурсов, оперативной памяти и дискового пространства. После развертывания отдельно следует проверить доступ, обновления, сетевые правила и резервное копирование.

Кратко

• До настройки VPS нужно проверить версию Ubuntu, сеть, диски, время и доступ к консоли провайдера.
• Для повседневной работы лучше создать отдельного пользователя с правами sudo.
• SSH-ключ необходимо проверить в новом сеансе до отключения парольного входа.
• После развертывания следует установить доступные обновления и проверить необходимость перезагрузки.
• UFW включают только после добавления разрешающего правила для SSH.
• Открывать следует только те порты, которые действительно нужны установленным приложениям.
• Резервные копии должны храниться отдельно от рабочего виртуального диска.
• Работоспособность backup подтверждается только тестовым восстановлением.