VPS и SSH: доступ к учебному серверу

До этого мы описывали артефакт и внешние условия публикации. Теперь подготовим место, куда издатель сможет передать выпуск. Рассмотрим выделенный учебный VPS с Ubuntu 24.04 LTS. На виртуальном хостинге Beget системное администрирование выполняет площадка; приведённые настройки относятся именно к серверу, которым вы управляете самостоятельно.

Условный адрес VPS — 203.0.113.10. Это документационный адрес, поэтому команды показывают будущую последовательность, а не подключение к работающему серверу. Вводные права администратора предоставлены владельцу стенда через площадку. Наша задача — получить проверяемый обычный доступ и подготовить каталоги, не связывая каждую загрузку статических файлов с административной учётной записью.

Что даёт SSH и что нужно проверить первым

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

Ключ пользователя и ключ сервера решают разные задачи. Первый доказывает право пользователя подключиться; второй помогает клиенту узнать сервер. Публичную часть пользовательского ключа добавляют в разрешённые ключи учётной записи, закрытую оставляют на устройстве владельца или в специально подготовленном хранилище CI. Не следует копировать закрытый ключ в публичный каталог сайта. Даже если веб-сервер не отдаёт этот файл сейчас, его размещение там нарушает границу между приложением и доступом к машине.

ssh-keygen -t ed25519 -f ~/.ssh/release_lab_ed25519
ssh -i ~/.ssh/release_lab_ed25519 publisher@203.0.113.10

У ssh-keygen можно задать парольную фразу; для личного ключа она добавляет защиту при утрате устройства. Для автоматического доступа проектируют отдельный механизм и отдельный ключ, а не убирают защиту с личного. В примере имя publisher появится после создания учётной записи администратором. Попытка подключиться до этого этапа должна закончиться отказом, а не побуждать открывать сервер всем пользователям.

Роль издателя и роль веб-сервера

Издатель доставляет файлы, а веб-сервер читает их для ответа посетителю. Для статики серверу не требуется изменять статьи или выпускать архивы. Поэтому подготовим владельца publisher и группу чтения www-data. Издатель сможет создавать каталоги выпусков, Nginx — читать выбранный результат. Роль администратора останется для установки пакетов и изменения системной конфигурации; её не нужно использовать для каждой передачи HTML.

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

sudo adduser publisher
sudo usermod -aG www-data publisher
sudo install -d -o publisher -g www-data -m 2750 /srv/release-lab
sudo install -d -o publisher -g www-data -m 2750 /srv/release-lab/releases
sudo install -d -o publisher -g www-data -m 2750 /srv/release-lab/shared

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

Изменять вход поэтапно

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

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

sudo sshd -t
sudo systemctl reload ssh

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

Передача без публикации

Первую загрузку направим в отдельный каталог входящих артефактов, а не прямо в current/public. Тогда оборванная передача не изменит сайт. Издатель получает архив, проверяет его паспорт и только затем готовит каталог выпуска. Если каталога current пока нет, это означает, что сайт ещё не выбран, а не что следует наугад копировать файлы в системный корень Nginx. Само подключение по SSH завершает лишь подготовку канала управления.

scp -i ~/.ssh/release_lab_ed25519 release-r2.tgz \
  publisher@203.0.113.10:/srv/release-lab/incoming/

Каталог incoming предварительно создают с нужными правами; команда не предполагает его автоматическое появление. Архив не содержит секретов окружения и не распаковывается с root-правами поверх произвольных путей. Размер свободного места проверяют до передачи большого выпуска: наличие SSH-доступа не гарантирует, что диск способен вместить новый каталог и сохранённую прежнюю версию.

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

В результате урока известны сервер, способ восстановления доступа, личность издателя и расположение выпуска. Теперь можно перейти к Nginx: определить, какие пути он отдаёт, как возвращает настоящую ошибку 404 и почему HTML с именем .php не нужно отправлять в PHP-FPM.