Это первая статья серии «Эксплуатация VPS / DevOps-база». Раньше мы говорили о том, как устроить систему: делить ли приложение на части (Монолит против микросервисов), как части договариваются (Проектирование API), что ускорить кэшем (Кеширование). Это всё — чертёж здания. Теперь вопрос проземлённее: а на чём это здание стоит? У вас свой сервер, вы платите за него каждый месяц, и если он сломается, чертёж вам не поможет — встанет сайт.
VPS (virtual private server, «виртуальный частный сервер») — это кусок чужой большой машины, который ведут себя как отдельный компьютер: у него свои IP-адрес, операционная система, память и диск, но физически всё это делится с соседями-арендаторами на одном настоящем сервере. Берут его у облачных провайдеров — об этом уже есть отдельная статья на сайте про выбор облака и тарифа; здесь мы предполагаем, что VPS уже куплен, OS выбрана (возьмём чистую Ubuntu) и перед нами мигающий чёрный экран с приглашением войти.
Что будет, если сесть на голый сервер и ничего не настроить? Ничего страшного сразу не случится — страшное начнётся потом, когда вы забудете, как вошли, оставите пароли на всех дверях и положите сайт под root. Сервер — штука терпеливая и равнодушная: он месяц молча копит то, что вы сделали неправильно, а потом отдаёт это разом в одну неудачную ночь. Поэтому первая статья серии про самое скучное и самое важное: как правильно поставить сервер на ноги, чтобы всё остальное — веб-сервер, база, мониторинг — ложилось на нормальный фундамент, а не на костыли.
Мы пройдём путь длиной в один вечер: зайдём по SSH, создадим себе отдельное (не root) имя, научимся входить по ключу вместо пароля, закроем root-вход по паролю и наведём базовую гигиену — имя машины, язык, время и подстраховку от нехватки памяти. В конце у вас будет сервер, на который не страшно ставить то, что вы будете строить в следующих восьми статьях.
Часть I. Что такое VPS и чем он отличается от хостинга «под ключ»
Начнём с вопроса, который кажется простым, но путает всех на старте: зачем вообще VPS, если есть обычный хостинг, где сайт работает «сам»?
1. Три способа держать сайт, от простого к сложному
Представьте три варианта аренды жилья:
- Shared-хостинг («общий хостинг») — как общежитие: один сервер, десятки сайтов, вам дали «угол» с панелькой управления. Ничего настраивать не надо, но и трогать ничего нельзя — захотите нестандартный модуль PHP или свою версию nginx, и упрётесь в «так не положено». Дёшево, просто, тесно.
- VPS (виртуальный частный сервер) — как отдельная квартира в доме: вам дают чистую операционную систему (обычно Ubuntu или Debian), полный доступ к ней, но дом и коммуникации (физическое железо, сеть) общие с другими квартирами. Вы — хозяин: ставьте что хотите, но и чините что сломали тоже вы.
- Выделенный сервер / своё железо — как свой дом на участке: всё физически ваше, максимум контроля, максимум ответственности и цена.
VPS — это баланс: почти как свой компьютер, но за разумные деньги. Именно поэтому self-hosted WordPress на VPS так популярен: панель управления хостинга надоедает лимитами, а свой сервер даёт свободу — за ту же цену, что «жирный» тариф у хостера.
2. За что вы платите и чего в коробке нет
Когда провайдер даёт вам VPS, в «коробке» лежат:
- IP-адрес — адрес, по которому мир будет стучаться к вашему сайту (бывает ещё и обратный — по нему вас опознают);
- Операционная система — обычно вы выбираете образ при покупке: возьмём Ubuntu (или Debian — почти то же, команды совпадут);
- Ограниченные ресурсы — сколько ядер CPU, гигабайт памяти, гигабайт диска. Для маленького сайта часто хватает 1–2 ядер и 1 ГБ оперативки — и вот эта «оперативка» потом окажется самым нервным местом.
- Доступ по SSH — то самое чёрное окно, через которое вы будете делать с сервером всё.
Чего в коробке нет: у вас нет графического интерфейса (мышкой по папкам не походить, всё командами), нет гарантий, что сервер не упадёт (это теперь ваша работа — см. статьи про мониторинг и диагностику), и нет никого, кто защитит вас от спама ботов на SSH — сеть вокруг сервера токсичная с первой секунды.
3. Почему голый сервер — это на самом деле хорошо
Новичок боится пустого терминала: «я ничего не поставил, всё сломается». Опытный VPS-хозяин любит пустой сервер — на нём нет лишнего. Чем меньше установленных программ, тем меньше дыр, меньше обновлений и меньше непонятного в логах. Хороший сервер годами остаётся скучно-пустым внутри: nginx, PHP-FPM, база и пара утилит — всё, что нужно одному сайту. В следующих статьях мы и будем аккуратно добавлять на этот чистый лист ровно то, что нужно WordPress, — не больше.
Термин на будущее: самохостинг (self-hosting) — когда сервер и всё на нём ведёте вы, а не провайдер «под ключ». Вся эта серия — про то, как self-hosting пережить.
Часть II. Первый вход по SSH
SSH (Secure Shell) — протокол и программа для удалённого входа в командную строку другого компьютера по сети. Всё, что вы умеете в терминале, вы теперь умеете и на сервере, толькочерез сетевой шнур. SSH шифрует передачу, поэтому пароли не летят по сети открытым текстом.
1. Что понадобится
С любой машины (Windows/macOS/Linux), с которой вы будете управлять сервером:
- Адрес сервера — IPv4 вида
203.0.113.42или домен (напримерserver.example.test); - Пользователь — при первом входе обычно это
root(суперпользователь) илиubuntu(готовый образ Ubuntu так называет первого юзера); - Пароль — тот, что провайдер дал вам в письме при покупке;
- Программа ssh — на Linux/macOS уже есть в терминале; на Windows 10+ встроен OpenSSH (терминал →
ssh), либо ставят PuTTY/Windows Terminal.
2. Само подключение
# заходим на сервер под root (пароль попросит после — введите и не пугайтесь,
# при вводе пароль в SSH не отображается даже звёздочками — это нормально)
ssh root@203.0.113.42Вас встретит сообщение про неизвестный ключ хоста («Are you sure you want to continue connecting?»). Это SSH впервые видит этот сервер и спрашивает, доверять ли его «отпечатку». На первом входе в свой свежий сервер — да, доверяйте. (Правило на будущее: если такой вопрос появится повторно, когда вы уже входили — вот это тревожный сигнал, возможен перехват соединения; тогда стоп и проверяйте, не менялся ли сервер.)
Успех — в приветствии меняется приглашение:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux ...)
...
root@ubuntu:~#Обратите внимание на root@ubuntu:~# — вы сейчас root (в конце символ #, у обычного пользователя там $). Это временно: в Части III мы уходим от root-входа.
3. Разведка: что за машина под вами
Прежде чем что-то ставить, полезно посмотреть, что именно вам досталось. Несколько безопасных команд на чтение:
# версия системы
lsb_release -a
# сколько памяти и где она ушла
free -h
# сколько места на диске
df -h /
# сколько ядер CPU
nproc
# загрузка за последние 1/5/15 минут (три числа; ориентир — не больше числа ядер)
uptimeЕсли free -h показал 0.5–1 ГБ памяти — это и есть типичный маленький VPS. Запомните это число: к нему мы вернёмся в Части V, когда будем делать swap, потому что на такой памяти легко и красиво «убить» PHP, не заметив.
4. Обновить систему — первое полезное действие
Сразу после входа (пока вы root) — навести порядок в пакетах (пакет = устанавливаемая программа):
# обновить список доступных пакетов
apt update
# установить обновления безопасности (по умолчанию спросит подтверждение)
apt upgradeapt (Advanced Package Tool) — штатная утилита Ubuntu/Debian для установки и обновления программ. update подтягивает «витрину» свежих версий, upgrade реально достанавливает новые версии. Это не про «включить автозагрузку сайта», а про то, чтобы ваша система не начинала жизнь со свежих дыр в пакете. Про регулярные обновления без простоя будет отдельная статья №7 серии — здесь первый раз и «вручную».
Теперь, когда система хотя бы актуальна, самое время перестать быть root.
Часть III. Почему нельзя работать под root и как это исправить
Короткий ответ: root (он же «суперпользователь», UID 0) может всё — и не прощает ошибок. Работать от него в терминале каждый день то же самое, что варить суп бензозаправкой: мощность есть, но один неверный жест — и хана.
1. Одна команда, и сайта нет
Два классических способа разнести сервер под root:
- опечатка в пути при удалении;
- скрипт/команда, которую вы не до конца поняли.
# ЭТО НЕ ВЫПОЛНЯТЬ — пример катастрофы: удаление с опечаткой в пути.
# rm -rf /home/example/ ← аккуратно, со слешем на конце и проверкой
# rm -rf /home/example /* ← лишний пробел превращает в «удали ВСЁ в /»Под обычным пользователем такая ошибка снесёт только его файлы — система уцелеет, вы всё почините. Под root она снесёт саму систему, и восстанавливать сервер придётся переустановкой. Поэтому правило №1 администрирования: root — только для команд, которым нужна власть, и только через sudo, а живём под своим именем.
2. Создаём себе пользователя
Дальше — вводим команды от root. Создадим пользователя deploy (имя любое, смысл — «разворачивающий/хозяин сайта»):
# создать пользователя с домашней папкой и оболочкой bash
adduser deploy
# у adduser будет спрос пароля и анкетных данных — пароль придумайте надёжный и
# запишите: это ваш основной пароль на сервер, его взлом = взлом сервераadduser (а не голое useradd) сам заведёт домашнюю папку /home/deploy, спросит пароль и всё настроит по-человечески.
Теперь даём ему право «иногда становиться root» через sudo (su-DO, «сделать как root»):
# добавить deploy в группу sudo — на Ubuntu/Debian участники группы sudo имеют право sudo
usermod -aG sudo deploysudo работает так: вы под deploy, но перед командой, которой нужна власть, пишете sudo — система спросит ваш пароль и выполнит команду от root, на один раз. Вся сила root заперта за sudo, а не открыта всем подряд как у root-входа.
3. Проверяем, что sudo работает
Не отключая текущую root-сессию (!) открываем второе окно/вкладку на сервере:
ssh deploy@203.0.113.42Если зашло — пробуем власть:
sudo apt update
# попросит пароль deploy; выполнится от root
sudo whoami
# должно ответить rootПочему не отключаем root-окно: если что-то в настройках нового пользователя сломано (например, нет права sudo), вы не останетесь с заблокированным сервером без входа. Первую ночь всегда держим запасную дверь (root-сессию) открытой, убеждаемся, что новая работает, и только потом её прикрываем (в Части IV отключим вход под root и по паролю).
4. Куда дальше исчезает root
С этого момента ваш нормальный путь: заходить под deploy, а «тяжёлые» команды запускать через sudo. Это и есть корпоративная гигиена на одной машине. Дальше в статье все команды, требующие власти, будут даны с sudo — вводите их, уже будучи deploy (или root в запасной сессии — совпадёт).
Часть IV. Ключ вместо пароля
Пароль SSH-сервера — главная дверь. И вокруг сервера круглосуточно ходят боты (это не преувеличение, а статистика любого свежего VPS: лог auth.log заполняется попытками входа за минуты). Они перебирают пароли из словарей и баз утёкших дампов. Пароль qwerty123 взломают за часы; даже сложный — это мишень, которую надо знать и вспомнить. Ключ вместо пароля убирает мишень: угадать его нельзя.
1. Что такое SSH-ключ простыми словами
SSH-ключ — это криптографическая пара из двух файлов:
- приватный ключ — секрет, лежит только на вашей машине и никому не отдаётся;
- публичный ключ — «замок», который кладут на сервер; что им заперто — откроется только парным приватным.
При входе сервер отправит «подпись» своим публичным замком; ваш компьютер подтвердит её своим приватным ключом. Без приватной части подтвердить невозможно, а перебрать миллиарды вариантов подписи — физически не выйдет (в отличие от короткого пароля). Пароли при этом не нужен — если вы задали ключу кодовую фразу (passphrase), о чём ниже.
2. Генерируем ключ на своей машине (не на сервере!)
Работаем в терминале вашего ноутбука/ПК:
# создать пару ключей; -t ed25519 — современный короткий и надёжный алгоритм
# -C "you@example.test" — метка-комментарий, кому ключ (в файл не пишется секрет)
ssh-keygen -t ed25519 -C "my-vps-access"
# спросит куда сохранить (Enter → по умолчанию ~/.ssh/id_ed25519)
# спросит passphrase — ДА, задайте: это пароль на сам ключ, без него украденный
# ключ = готовый доступ; с passphrase похищенный файл бесполезен без пароля к немуПосле этого в папке ~/.ssh/ лежат id_ed25519 (приватный, никому!) и id_ed25519.pub (публичный, тот кладём на сервер).
Если
ed25519не поддерживается (старый клиент) — используйтеssh-keygen -t rsa -b 4096 -C "my-vps-access"(длиннее, но надёжно).
3. Кладём публичный ключ на сервер
Вариант А — утилитой (со своей машины, с паролем ещё по паролю):
# скопирует ваш .pub на сервер в authorized_keys под root или deploy
ssh-copy-id deploy@203.0.113.42Вариант Б — руками (если ssh-copy-id нет, например на чистом Windows-клиенте). На сервере под deploy:
# на сервере: создаём папку и файл, куда SSH смотрит при входе по ключу
mkdir -p ~/.ssh
# вставить содержимое id_ed25519.pub (оно выглядит как "ssh-ed25519 AAAA... метка")
# одной строкой в конец файла:
echo 'ssh-ed25519 AAAA...ваш_ключ_тут... my-vps-access' >> ~/.ssh/authorized_keys4. Права доступа — это критично, SSH придирчив
SSH откажет работать с ключом, если права на файлы «слишком открытые» (сосед по машине сможет подменить ключ). Строго:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys700 = «только владелец читает/пишет/заходит в папку», 600 = «только владелец читает/пишет файл». Если SSH после настройки ключа всё ещё требует пароль — почти всегда виноваты именно права.
5. Проверяем вход по ключу (отдельным окном, запасную дверь не закрываем)
На своей машине:
# -i указывает приватный ключ; обычно под ~/.ssh/id_ed25519 SSH сам его подберёт
ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.42
# должно пустить БЕЗ пароля, только спросить passphrase если задавалиРаботает — отлично. Дальше обязательный шаг, иначе ключ не защищает:
6. Отключаем парольный вход и root-вход (только когда ключ точно работает!)
Правим конфиг SSH-демона на сервере. Аккуратно: после ошибки можно отрубить себе вход.
# бэкап конфига перед правкой
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
# открыть в редакторе
sudo nano /etc/ssh/sshd_configНайти и раскомментировать (убрать #) / поставить нужные значения:
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yesPasswordAuthentication no— вход только по ключу, перебор ботами паролей не сработает (их сразу отбивает).PermitRootLogin no— root не входит из сети вообще; злоумышленнику нужно ещё и скомпрометироватьdeploy.PubkeyAuthentication yes— ключи работают (обычно и так включено).
Валидация конфига до перезапуска (ловит опечатку, которая иначе выбьет SSH):
# проверить синтаксис sshd_config, НЕ прерывая текущие соединения
sudo sshd -t && echo "конфиг OK"Только если конфиг OK — перезапускаем службу (пока вы root или с sudo, и не закрывая текущую сессию):
# systemctl — утилита управления службами Linux; подробный разбор в статье №2
sudo systemctl restart ssh
# на некоторых системах служба называется sshdТеперь открываем новое окно и пробуем ssh deploy@... — пускает по ключу. Пробуем ssh root@... — должно отказать (Permission denied). Если новое окно пускает, а вы где-то ошиблись — в старой запасной root-сессии всё ещё есть вход, и можно откатить конфиг из бэкапа. Убедившись, закрываем root-сессию навсегда: с этого момента у вас один путь на сервер — ключ под deploy.
Частый страх новичка: «потеряю ключ — не зайти». Держите бэкап приватного ключа (и/или второй ключ с другим именем в
authorized_keys) в надёжном месте — в менеджере паролей, не в облаке «файлом как есть». Аварийный вход по паролю обычно отключают полностью — и правильно, но имейте запасной ключ, а не запасной пароль.
Часть V. Базовая гигиена сервера: имя, локаль, время, память
Сервер почти готов, но есть четыре мелочи, которые экономят часы на отладке. Делаются по-быстрому, забываются — и потом кусают локти на «почему логи по времени не совпадают с сайтом».
1. Имя машины — чтобы понимать, где ты
В приглашении терминала вы видите deploy@ubuntu. ubuntu — это hostname, имя машины. Если у вас появится второй сервер, а имена у обоих ubuntu, вы будете вводить команды не на том. Задаём осмысленное:
# hostnamectl задаёт имя системы сразу и переименовывает в приглашении
sudo hostnamectl set-hostname web01.example.test
# после этого перелогиньтесь, чтобы увидеть новое имяИмя должно совпадать с тем, что прописано в /etc/hosts — иначе некоторые программы будут задумываться:
# проверить /etc/hosts: строка вида "127.0.0.1 localhost web01.example.test"
sudo nano /etc/hostsДомен example.test — зарезервированный для примеров (никогда не резолвится наружу), безопасная заглушка для конфигов.
2. Локаль и язык — чтобы вывод был привычным
# поставить русскую/английскую локаль и кодинг UTF-8
sudo apt install -y locales
sudo locale-gen ru_RU.UTF-8
sudo update-locale LANG=ru_RU.UTF-8Практического смысла у этого немного, но один есть: с корректной UTF-8 локалью date и логи печатают месяцы понятно, а файлы с русскими именами не превращаются в ??????.
3. Часовой пояс — критично для логов и cron
По умолчанию сервер живёт в UTC. Само по себе это нормально (и даже хорошо, что логи сервера в UTC). Но WordPress, cron-задачи и вы сами думаете в своём времени, и расхождение в +3 часа (для Москвы) сбивает с толку, когда ищешь «когда упал сайт»:
# показать текущий часовой пояс и время
timedatectl
# поставить местное время (пример для Москвы)
sudo timedatectl set-timezone Europe/MoscowВажный выбор на будущее: где хранить логи/БД — в UTC или местном? Одно значение должно быть во всей системе. Проще: ОС в UTC, локальное время только в отображении. Но если вся команда в одном часовом поясе — ставят местный, как выше. Смешивать нельзя: иначе cron сработает «не в тот час», а бэкап «не в тот день».
4. Проверка синхронизации времени
Время на сервере должно идти точно — иначе TLS-сертификаты «ещё не действуют / уже истекли», cron врёт, логи не стыкуются. Ubuntu обычно сам держит время через systemd-timesyncd:
# увидеть, синхронизировано ли время с NTP
timedatectl show-timesync --all | grep -i synced
# быстрая визуальная проверка, что часы не отстают
dateЕсли NTPSynchronized=no — время сядет за часы, и это отдельная проблема (чинится timedatectl set-ntp true).
5. Swap — подстраховка от нехватки памяти (самая частая на VPS)
На машине с 512–1024 МБ RAM однажды PHP-процесс съест память, ядро Linux не найдёт куда её положить и включит OOM-killer (Out-Of-Memory, «убийца нехватки памяти») — тот методично убивает процессы, часто выбрав самый жирный, то есть вашу базу или PHP-воркер. Сайт лежит, и вы в шоке гуглите «почему mysql упал в 3 ночи».
Swap (своп, «файл подкачки») — место на диске, куда ОС временно выгружает неиспользуемые куски памяти. Это меднее RAM, но спасает от убийства процессов. Диск VPS «бесплатный», памяти нет — меняем их частично.
# создать swap-файл 2 ГБ (для машины с 1–2 ГБ RAM; 4 ГБ RAM → 1 ГБ swap)
sudo fallocate -l 2G /swapfile
# если fallocate недоступен на этой ФС — через dd:
# sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
# строгие права: swap-файл содержит фрагменты памяти других процессов!
sudo chmod 600 /swapfile
# «форматируем» под swap и включаем
sudo mkswap /swapfile
sudo swapon /swapfile
# чтобы пережил перезагрузку — прописываем в fstab
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# проверяем:
free -h # в строке Swap должен появиться объёмРазмер подбирают по ситуации: ориентир — swap ≈ объём RAM (минимум 1 ГБ). На маленьком VPS swap замедлит «на пределе», но это в сто раз лучше убивания процессов. Регулируемую «жадность» к использованию swap (параметр swappiness) тонко настраивают реже — на одной машине по умолчанию почти всегда ок.
Swap лечит нехватку, а не утечку. Если процесс жрёт память непрерывно (баг), swap лишь отсрочит аварию на минуты. Настоящее решение — правильные лимиты PHP-FPM (статья №4 серии) и мониторинг (статья №8).
6. Что ещё полезно проверить в конце гигиенического прохода
# открытые порты, на которые кто-то может постучаться (сейчас это SSH; веб-сервера ещё нет)
sudo ss -tulpn
# текущие пользователи и входы
last -n 5
# сколько места осталось (вдруг VPS пришёл с уже занятым диском)
df -hСписок открытых портов сейчас: один 22/tcp (SSH). Так и должно быть — до момента, когда в статье №3 вы поднимете 80/443 под сайт. Всё остальное время «лишние слушающие порты» = лишние двери.
Часть VI. Что у нас получилось и куда идти
Итак, фундамент стоит:
- вы не root и входить по паролю ботам больше некуда (SSH по ключу, root-вход и пароль закрыты);
- есть пользователь
deployсsudo; - система актуальна (
apt upgradeпрогнан, автообновления наладим в статье №7); - имя машины понятное, локаль/время/часовой пояс заданы;
- память подстрахована swap-файлом, лишние порты не слушаются.
Это «чистый и скучный сервер с одним сайтом в планах». Никакого WordPress и nginx здесь нет намеренно: сначала фундамент, потом надстройки. В следующих восьми статьях серии мы аккуратно поставим на это всё, что нужно сайту, и научимся это чинить.
Чек-лист граблей этой части
- Не закрывали root-сессию, пока не проверили новый вход в отдельном окне. Классика самоблокировки: отрубили парольный/root-вход → новое окно не пускает → старый root уже закрыт. Держите запасную дверь до подтверждения.
- `sshd -t` перед `systemctl restart ssh` — иначе опечатка в конфиге положит SSH, и вы на морозе без входа.
- Права на `~/.ssh` (700) и `authorized_keys` (600) — SSH молча игнорирует ключ при открытых правах, а вы гадаете «почему требует пароль».
- Публичный ключ не обрезан при ручной вставке — одна потерянная символа в base64-теле, и ключ «не валится».
- Passphrase на приватный ключ задана — без неё украденный `id_ed25519` = готовый доступ без всякого пароля.
- Swap-файл прописан в `/etc/fstab` — иначе после первой же перезагрузки swap исчезнет, а вы не заметите до первой ООМ-аварии.
- Часовой пояс выбран один для всей системы и не смешивается (UTC в ОС + местный в cron = «задачи не в тот час»).
- Бэкап приватного ключа лежит в надёжном месте (менеджер паролей), а не «одной папкой в облаке».
- Не забыли `chmod`/права на файлы, созданные под root через sudo (например `authorized_keys` у deploy) — иногда root создаёт их как root в чужой домашней папке, и SSH потом «не видит» из-за владельца.
Материал написан простым языком; любой англоязычный термин (SSH, sudo, swap, OOM-killer, hostname, VPS, shared-хостинг) объясняется при первом употреблении. Команды даны для Ubuntu/Debian с
apt/systemd; конкретные номера версий пакетов опускаются сознательно — сверяйте поддержку и поведение по официальной документации дистрибутива. Все домены в примерах —example.test(зарезервированный тестовый домен, наружу не резолвится).
👤 Зарегистрируйтесь, чтобы добавить материал в закладки.