Як змінити пароль root для VPS на Ubuntu

Як змінити пароль root для VPS на Ubuntu

Щоб змінити пароль root для VPS (virtual private server) на Ubuntu, відкрийте сеанс SSH (secure shell) від імені користувача, який може виконувати sudo, а потім виконайте sudo passwd root. Команда двічі запитує новий пароль і не запитує старий, оскільки sudo уже підтвердив вашу особу. Щоб змінити власний пароль для входу, виконайте passwd без аргументів. Спочатку команда запитає поточний пароль.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Це вся операція. Нижче описано типові проблеми: як перевірити новий пароль, перш ніж втратити сеанс, через який можна було б виправити помилку; як задавати паролі зі скрипту; як навмисно завершити строк дії пароля; і як відновити доступ, якщо пароль уже втрачено.

Відкрийте другу сесію, перш ніж змінювати пароль

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

Уже відкрита оболонка продовжує працювати після зміни, блокування або завершення дії облікового запису, якому вона належить, оскільки SSH перевіряє облікові дані під час входу й не перевіряє їх повторно. Винятком є sudo. Він повторно перевіряє пароль через PAM (pluggable authentication modules), коли спливає мітка часу — за замовчуванням через 15 хвилин після останнього запиту. Тому новий пароль уперше проходить реальну перевірку наступного разу, коли sudo запитає його, а не під час входу.

Перевірте новий пароль у другій сесії, залишивши першу відкритою.

Зміна власного пароля за допомогою passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully — єдиний результат, який означає, що хеш у /etc/shadow замінено. У будь-якому іншому випадку старий пароль залишився без змін.

Тут виникають дві помилки. passwd: Authentication token manipulation error, а потім passwd: password unchanged означають, що введений поточний пароль неправильний або файлову систему, у якій міститься /etc/shadow, неможливо змінити. У режимі відновлення це стандартний стан. You must choose a longer password. надходить із pam_unix у /etc/pam.d/common-password. Цей файл застосовує перевірки довжини та схожості для звичайних користувачів.

У більшості образів VPS обліковий запис за замовчуванням (ubuntu або інша назва, з якою постачається образ) взагалі не має пароля, а використовує лише SSH-ключ. passwd не має поточного пароля для перевірки, тому не може пройти перший запит. Натомість використовуйте sudo passwd $USER. Це працює, оскільки додатковий файл sudoers образу дозволяє цьому обліковому запису виконувати sudo без пароля.

Зміна пароля іншого користувача за допомогою sudo passwd

sudo passwd deploy

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

Блокування — це окрема дія. sudo passwd -l deploy додає ! перед збереженим хешем, тому жоден пароль не відповідає йому. sudo passwd -u deploy видаляє цей префікс. Перевірте стан за допомогою sudo passwd -S deploy.

Блокування пароля не забороняє цьому користувачеві входити в систему. Будь-який ключ у його ~/.ssh/authorized_keys і далі працює, оскільки автентифікація за відкритим ключем не читає /etc/shadow. Щоб повністю заблокувати обліковий запис, завершіть термін його дії:

sudo usermod --expiredate 1 deploy

Це встановлює дату завершення дії облікового запису в 1970 році, тому sshd відхиляє вхід незалежно від наданих облікових даних. Скасуйте цю зміну за допомогою sudo usermod --expiredate '' deploy.

Не використовуйте passwd -d. Команда встановлює порожній пароль, а не блокує його. У старішому випуску, де в стеку PAM досі є nullok, порожній пароль може використати будь-хто.

Чи потрібен root пароль на VPS?

В Ubuntu root заблокований за замовчуванням. /etc/shadow містить ! замість хешу, а sudo passwd -S root виводить рядок, що починається з root L. Увійти як root за паролем неможливо, доки ви не встановите для нього пароль. Саме тому образ надає користувача з правами sudo. Працюйте через облікові записи користувачів із мінімальними привілеями на VPS, а не від імені root.

Встановлення пароля root дає лише одну конкретну перевагу: можливість увійти через консоль провайдера. Ця консоль підключається до віртуальної машини нижче рівня мережевого стека. Тому вона працює навіть тоді, коли конфігурацію sshd пошкоджено або правило firewall задано неправильно. Але це має і недолік. Меню відновлення GRUB запитує пароль root, якщо для root встановлено пароль. Отже, інструмент, який ви використали б для скидання забутого пароля, тепер захищений цим самим паролем.

Встановлення пароля root не дозволяє root входити через SSH. В Ubuntu за замовчуванням використовується PermitRootLogin prohibit-password, тобто дозволено лише автентифікацію за ключами. Перевірте, що насправді використовує ваш сервер:

sudo sshd -T | grep -i permitrootlogin

sshd -T виводить ефективну конфігурацію після обробки кожного рядка Include. Тому це єдиний достовірний спосіб перевірки, якщо /etc/ssh/sshd_config.d/ містить drop-in файли.

Установлення пароля зі скрипту за допомогою chpasswd

passwd читає дані з термінала, тому ним не можна керувати зі скрипту. chpasswd читає пари user:password зі стандартного вводу, по одній парі в кожному рядку.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Це працює, але записує пароль у відкритому вигляді в історію оболонки та журнали CI (continuous integration). Спочатку створіть його хеш:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 двічі запитує пароль без відображення введених символів, а потім виводить хеш SHA-512 crypt, який починається з $6$. -e повідомляє chpasswd, що друге поле вже містить хеш, тому його без змін копіюють у /etc/shadow. Хеш безпечно зберігати в репозиторії або змінній CI, а пароль у відкритому вигляді не залишає машину, на якій ви його ввели.

Ubuntu 24.04 хешує нові паролі за допомогою yescrypt ($y$), коли passwd встановлює їх, тоді як openssl passwd -6 використовує SHA-512. Обидва формати перевіряються під час входу, оскільки libxcrypt підтримує їх обидва. Їх можна змішувати, а openssl passwd -6 працює однаково в усіх випусках Ubuntu LTS, на відміну від chpasswd -c YESCRYPT: старіший пакет shadow в 20.04 не знає цієї назви методу. Ці хеші зберігаються і після оновлення до нового випуску, тому перехід сервера з 24.04 на 26.04 не змушує скидати паролі користувачів.

Як перевірити, що пароль справді змінено?

Спочатку перевірте метадані, а потім підтвердьте зміну входом.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

Друге поле містить стан: P для робочого пароля, L для заблокованого пароля, NP за повної відсутності пароля. Дата показує, коли пароль змінювали востаннє, тому там має бути сьогоднішня дата. Числа після неї — це параметри старіння пароля, описані нижче.

Найбезпечніша перевірка в робочій системі — виконати sudo. sudo -k відкидає кешовану часову мітку, а sudo -v примусово виводить новий запит. Якщо новий пароль прийнято, PAM його прийняв, і параметри поточного сеансу не змінилися.

sudo -k && sudo -v

Щоб перевірити інший обліковий запис, виконайте su - deploy з оболонки непривілейованого користувача. Не виконуйте sudo su - deploy, оскільки root ніколи не вводить пароль, тому така перевірка нічого не доводить. Неправильний пароль виводить su: Authentication failure.

Справжня перевірка — новий SSH-вхід із вашого ноутбука, поки робочий сеанс залишається відкритим:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). означає, що сервер взагалі не запропонував автентифікацію за паролем, тому жодна зміна пароля не дасть змоги ввійти. Permission denied, please try again. означає, що сервер її запропонував, але відхилив введені вами дані.

Змусьте користувача змінити пароль під час наступного входу за допомогою chage

sudo chage -d 0 deploy

-d 0 встановлює дату останньої зміни пароля в epoch, тому PAM вважає пароль простроченим. Під час наступного інтерактивного входу система запитує поточний пароль, а потім новий, перш ніж надати shell. sudo passwd -e deploy робить те саме.

Використовуйте це лише для облікових записів, які входять інтерактивно за паролем. Прострочений пароль також впливає на входи за ключем, оскільки sshd виконує етап PAM account навіть тоді, коли автентифікацію виконано за допомогою ключа. Скрипт із ssh deploy@203.0.113.10 'systemctl restart app' після цього завершується з такою помилкою:

Password change required but no TTY available.

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

Що означають поля терміну дії пароля

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Ці числа — поля з 4 по 8 у рядку цього користувача у /etc/shadow. Мінімальна кількість днів (chage -m) визначає, скільки часу користувач має чекати перед наступною зміною пароля. Це не дає одразу повернутися до старого пароля після примусової зміни. Максимальна кількість днів (chage -M) визначає, як довго пароль залишається дійсним. Кількість днів для попередження (chage -W) визначає, коли під час входу починає виводитися попередження. Кількість неактивних днів (chage -I) — це пільговий період після завершення терміну дії, протягом якого пароль ще приймається. Завершення терміну дії облікового запису (chage -E) — це фіксована дата, яка не залежить від пароля.

sudo chage -M 90 -W 14 deploy

Встановлюйте це поле лише тоді, коли цього вимагає політика. NIST (Національний інститут стандартів і технологій США) з 2017 року не рекомендує регулярно змінювати паролі після завершення терміну їх дії. Така практика спонукає користувачів створювати передбачувані варіації одного пароля. Натомість NIST рекомендує примусово змінювати пароль, якщо є ознаки його компрометації. Довгий унікальний пароль, збережений у password manager, у поєднанні з SSH на основі ключів надійніший за 90-денний цикл.

Що робити, якщо ви втратили пароль root

Якщо будь-який обліковий запис на сервері може виконувати sudo, відновлювати нічого не потрібно: sudo passwd root встановлює новий пароль. Складний випадок — коли немає жодного робочого входу.

Для всіх описаних нижче дій потрібна консоль провайдера. У більшості панелей вона називається VNC (virtual network computing) або serial console. Вона підключається до віртуальної машини під мережевим стеком, тому налаштування sshd і правила firewall на неї не впливають.

1. Перезавантажте сервер із панелі та стежте за консоллю.
2. Відкрийте меню GRUB. У cloud-образах зазвичай встановлено GRUB_TIMEOUT=0, тому під час завантаження через BIOS утримуйте Shift, а під час завантаження через UEFI одразу після початку перезавантаження кілька разів натискайте Esc.
3. Виберіть Advanced options for Ubuntu, потім запис, що закінчується на (recovery mode), а далі root у recovery menu.
4. Спочатку виконайте mount -o remount,rw /. Recovery монтує root filesystem лише для читання, тому без цієї дії passwd завершується помилкою passwd: Authentication token manipulation error, оскільки не може записати /etc/shadow.
5. Виконайте passwd ubuntu для потрібного облікового запису, а потім перезавантажте сервер із панелі.

Якщо для root уже встановлено пароль і саме його ви втратили, ця recovery shell попросить його ввести, тому цей спосіб не спрацює. Натомість завантажте rescue image провайдера, змонтуйте справжній диск і змініть пароль у змонтованій системі.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Перегляньте структуру розділів за допомогою lsblk, а не копіюйте /dev/vda1 із цієї сторінки. Root partition — найбільший. В образі UEFI він розташований поруч із невеликим EFI partition, у якому взагалі немає каталогу /etc.

Що робити, якщо SSH перестав приймати пароль

Працюйте з наявної сесії. Якщо активних сесій не залишилося, використайте консоль.

Permission denied, please try again. означає, що сервер запропонував автентифікацію за паролем, але відхилив надіслане значення. Зазвичай причиною є ввімкнений Caps Lock або розкладка клавіатури в консолі, яка відрізняється від розкладки під час встановлення пароля.

Permission denied (publickey). означає, що сервер взагалі не запропонував автентифікацію за паролем. PasswordAuthentication no десь встановлено, а в Ubuntu 22.04 і новіших версіях цей параметр зазвичай міститься у drop-in-файлі в каталозі /etc/ssh/sshd_config.d/, який перевизначає основний файл. Перевірте фактичні значення:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes разом із PasswordAuthentication no усе одно дає змогу ввійти за паролем, оскільки метод keyboard-interactive використовує той самий стек PAM. Якщо вимкнути один метод, а інший залишити ввімкненим, сервер, який виглядає як такий, що приймає лише ключі, продовжить приймати введені паролі.

Цей самий рядок також виводиться під час відхилення входу за ключем. Тому, якщо ви пропонували ключ, а не пароль, параметр пароля на сервері є лише однією з п’яти причин помилки Permission denied (publickey), а вивід ssh -v покаже, яка саме причина спрацювала.

Too many authentication failures у повідомленні про розрив з’єднання означає, що клієнт запропонував кілька ключів, перш ніж дійшов до пароля, а сервер досяг MaxAuthTries, значення якого за замовчуванням дорівнює 6. Примусово використайте лише один метод:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused на порту, який ще хвилину тому працював, зазвичай означає, що fail2ban, який стежить за SSH, заблокував вашу адресу після повторних невдалих спроб. Правило блокування за замовчуванням відхиляє пакет, а не відкидає його без відповіді, тому відмова надходить швидко, а не після очікування тайм-ауту. У консолі sudo fail2ban-client status sshd покаже заблоковані адреси, а sudo fail2ban-client set sshd unbanip 203.0.113.10 зніме блокування з вашої адреси.

Паролі — це проміжний етап, ключі — кінцевий стан

Пароль, який працює через SSH, може підбирати будь-який сканер в інтернеті. Перейдіть на автентифікацію за ключем, і спроби підбору пароля більше не матимуть значення. Створіть пару ключів, установіть відкриту частину та перевірте в другому терміналі, що вхід за ключем працює, перш ніж змінювати щось інше. У матеріалі Основи керування SSH-ключами описано створення ключів, authorized_keys і парольні фрази.

Потім вимкніть автентифікацію за паролем і перевірте це за допомогою sudo sshd -T, а не покладайтеся лише на змінений файл. У матеріалі Посилення захисту SSH на VPS описано решту параметрів sshd, які варто змінити, а матеріал Перші десять хвилин на новому VPS визначає порядок цих дій на щойно підготовленому сервері.

Після цього збережіть один пароль. Сервер, на якому дозволено вхід лише за ключем, зі зламаною конфігурацією sshd доступний тільки через консоль провайдера, а ця консоль запитує ім’я користувача та пароль. Обліковий запис із надійним збереженим паролем дає змогу виправити проблему за п’ять хвилин, а не перевстановлювати систему.

FAQ

Як змінити пароль root на VPS, якщо старий пароль невідомий?

Увійдіть як користувач, який може виконувати sudo, і виконайте sudo passwd root. Команда встановлює новий пароль без запиту старого, оскільки sudo уже автентифікував вас. Якщо жоден обліковий запис на сервері не може виконувати sudo, відкрийте консоль провайдера, перезавантажте сервер у меню відновлення GRUB, виберіть пункт оболонки root, виконайте mount -o remount,rw /, а потім passwd. Якщо для root уже встановлено пароль і саме його ви втратили, оболонка відновлення запросить цей пароль. У такому разі залишається використати rescue image провайдера, змонтувати диск і виконати chroot.

Чому passwd повідомляє "Authentication token manipulation error"?

Це повідомлення мають дві причини. Найпоширеніша — неправильна відповідь на запит Current password:. Рядок passwd: password unchanged під ним підтверджує, що нічого не записано. Інша причина — файлову систему неможливо записати. Саме це трапляється в режимі відновлення, оскільки / там змонтовано лише для читання. Виконайте mount -o remount,rw / і повторіть спробу.

Чи змінює зміна пароля Linux також пароль sudo?

Так. У sudo немає власного пароля. Він автентифікує вас через PAM за тим самим записом /etc/shadow, який використовують SSH і su. Тому для кожного облікового запису використовується один пароль. Саме тому перший запит sudo після зміни пароля є фактичною перевіркою. Виконайте sudo -k && sudo -v, щоб примусово викликати цей запит, поки поточний сеанс ще працює.

Чи зламає зміна пароля SSH-ключі або відкриті сеанси?

Ні. Автентифікація за відкритим ключем не читає /etc/shadow, тому ключі продовжать працювати після зміни пароля, після passwd -l і після chage -d 0. Уже відкриті сеанси залишаються активними, оскільки SSH перевіряє облікові дані лише під час входу. У поточному сеансі змінюється лише sudo. Воно запитує новий пароль після завершення 15-хвилинної дії мітки часу.

Як примусово змусити користувача змінити пароль під час наступного входу?

Виконайте sudo chage -d 0 deploy або sudo passwd -e deploy, що робить те саме. Збережена дата останньої зміни переміщується до epoch, PAM вважає пароль простроченим, а під час наступного інтерактивного входу користувач повинен встановити новий пароль до запуску оболонки. Не робіть цього для облікового запису, який скрипти використовують через SSH: тоді неінтерактивна команда завершується помилкою Password change required but no TTY available. і не запускається.