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

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

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

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

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

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

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

Уже відкритий shell продовжує працювати після зміни, блокування або завершення терміну дії облікового запису, якому він належить, оскільки SSH перевіряє облікові дані під час входу й більше їх не перевіряє. Винятком є sudo. Після завершення терміну дії мітки часу sudo повторно перевіряє пароль через PAM (модулі підключної автентифікації). Типово це відбувається через 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 налаштовано неправильно або правило брандмауера задано помилково. Водночас це має і недолік. Оболонка root у меню відновлення GRUB запитує пароль 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 (безперервної інтеграції). Спочатку обчисліть його хеш:

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 в Ubuntu 20.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 встановлює дату останньої зміни пароля на початок епохи, тому PAM вважає пароль простроченим. Під час наступного інтерактивного входу система запитує поточний пароль, а потім новий пароль, перш ніж надати оболонку. sudo passwd -e deploy виконує те саме.

Використовуйте це лише для облікових записів, які входять інтерактивно за паролем. Прострочений пароль також впливає на входи за ключем, оскільки sshd виконує етап перевірки облікового запису PAM навіть тоді, коли автентифікацію виконано за допомогою ключа. Сценарій 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 рекомендує примусово змінювати пароль, якщо є ознаки його компрометації. Довгий унікальний пароль, збережений у менеджері паролів, у поєднанні з SSH на основі ключів ефективніший за 90-денний цикл.

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

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

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

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

Якщо root уже має пароль і саме його ви втратили, оболонка відновлення запитає цей пароль, тому цей спосіб не спрацює. Натомість завантажте 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 із цієї сторінки. Кореневий розділ є найбільшим. В образі UEFI він розташований поруч із невеликим EFI-розділом, у якому взагалі немає каталогу /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. Якщо вимкнути один метод і залишити інший увімкненим, сервер, який виглядає як такий, що приймає лише ключі, продовжить приймати введені паролі.

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 — результат буде однаковим. Збережена дата останньої зміни переміщується до початку епохи, PAM вважає пароль простроченим, і під час наступного інтерактивного входу користувач має встановити новий пароль до запуску оболонки. Не застосовуйте це до облікового запису, який використовується скриптами через SSH: у такому разі неінтерактивна команда завершиться помилкою Password change required but no TTY available. і не буде виконана.