Чому б не лишитися під root?

Усе, що запускається від root, може зламати систему повністю, зокрема й одна друкарська помилка. До того ж боти насамперед підбирають ім'я 'root', і заборона входу під ним прибирає найпопулярнішу ціль. Окремий користувач із sudo дає паузу перед кожною привілейованою командою та журнал того, що виконувалося.

А якщо я себе заблокую?

Скористайтеся веб-консоллю в особистому кабінеті. Вона працює, навіть коли SSH зламаний або файрвол вас не пускає, — можна зайти й виправити sshd_config. Саме тому нового користувача перевіряють до того, як закрити сесію root.

Чи варто дозволяти sudo без пароля?

Для облікового запису людини лишіть запит пароля — це останній рубіж, якщо SSH-ключ витече. Sudo без пароля доречний для окремого користувача деплою, яким користується автоматизація, і лише для потрібних їй команд.

На Debian немає команди sudo. Чому?

Мінімальні образи Debian не завжди її містять. Встановіть її під root командою 'apt install -y sudo', потім додайте користувача до групи sudo.

Який порт SSH використовувати?

Той, що вказаний в особистому кабінеті. На тарифах із виділеним IP — порт 22 на вашій адресі, на NAT-тарифах — ваш персональний SSH-порт.

Як створити sudo-користувача на VPS і перестати працювати під root

Створюємо користувача з sudo на Ubuntu чи Debian, даємо йому SSH-ключ, перевіряємо й вимикаємо вхід під root — у такому порядку, що заблокувати себе не вийде.

Майже кожен новий VPS починається однаково: заходите під root, ставите кілька програм — і за місяць усе ще працюєте під root. Це нормально рівно до моменту, поки скопійований скрипт не видалить не той каталог. Звичайний користувач із sudo налаштовується за п'ять хвилин, і порядок дій тут важливіший за самі команди: помилитеся — і лишитеся ззовні.

Ось безпечна послідовність для Ubuntu 22.04/24.04 і Debian 12.

1. Створюємо користувача

Під root:

adduser deploy
usermod -aG sudo deploy

adduser запитає пароль і необов'язкові дані (там можна просто тиснути Enter). Пароль вигадайте справжній: ви вводитимете його для sudo. Якщо на мінімальному Debian команди немає, спершу виконайте apt install -y sudo.

2. Даємо йому SSH-ключ

Найпростіше скопіювати ключі root, зберігши правильного власника:

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

Якщо хочеться вручну:

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Неправильні права — класична причина, чому вхід за ключем мовчки не працює. SSH ігнорує authorized_keys, у який можуть писати інші користувачі.

3. Перевіряємо, нічого не змінюючи

Сесію root не закривайте. У новому терміналі:

ssh -p 22 deploy@203.0.113.10
sudo whoami

Підставте свою IP-адресу й порт — на NAT-тарифі це ваш персональний SSH-порт з особистого кабінету. Якщо sudo whoami виводить root, усе гаразд. Якщо вхід не вдався, у вас лишається вікно root, щоб це виправити.

4. Вимикаємо вхід під root

Тепер зачиняємо двері. Замість редагування основного конфігу створюємо невеликий файл-доповнення:

cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
EOF
sshd -t && systemctl reload ssh

sshd -t спершу перевіряє синтаксис. Зламаний конфіг плюс reload — саме так люди й опиняються в консолі. PasswordAuthentication no має сенс лише після того, як вхід за ключем для нового користувача працює, — а це ви щойно перевірили.

Відкрийте ще один термінал і переконайтеся, що root не пускають, а deploy заходить. Після цього закрийте стару сесію root.

5. За бажанням: sudo без пароля для автоматизації

Якщо скрипту деплою потрібен sudo без запиту пароля, дайте йому саме це й не більше:

visudo -f /etc/sudoers.d/deploy

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

Чесно кажучи, NOPASSWD: ALL спокусливий, але тоді вкрадений ключ дорівнює root. Обмежте правило командами, які справді виконує автоматизація.

Якщо щось пішло не так

Веб-консоль в особистому кабінеті не залежить ні від SSH, ні від файрвола. Зайдіть через неї, виправте файл у /etc/ssh/sshd_config.d/, зробіть reload — готово. Увесь процес відновлення ми розібрали в статті як повернути доступ до заблокованого VPS.

Що далі

Повністю перейдіть на вхід за ключами: автентифікація за SSH-ключем.
Приглушіть шум від перебору паролів: fail2ban.
Пройдіться рештою основ за чек-листом безпеки нового VPS.

Варіанти доступу для кожного тарифу описані в документації з доступу. Навіть Nano за $3 заслуговує на окремого користувача — це найдешевше покращення безпеки з можливих.