Как изменить пароль 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-сессию прямо сейчас и оставьте её подключённой. Почти любую ошибку в этом руководстве можно исправить за две минуты, пока активна хотя бы одна авторизованная оболочка, но если она закроется, потребуется физический доступ к консоли.

Уже открытая оболочка продолжает работать после того, как вы изменили, заблокировали или ограничили срок действия учётной записи, так как 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 настроена неверно или правило межсетевого экрана блокирует доступ. Однако это несет и риски. Оболочка root в меню восстановления GRUB запрашивает пароль root, если он задан, поэтому инструмент, который вы использовали бы для сброса забытого пароля, сам оказывается защищен этим же паролем.

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

sudo sshd -T | grep -i permitrootlogin

Команда sshd -T выводит итоговую конфигурацию после обработки всех директив Include, поэтому это единственный достоверный источник информации, если в /etc/ssh/sshd_config.d/ используются дополнительные файлы конфигурации.

Установка пароля из скрипта с помощью 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 даже при аутентификации по ключу. Скриптовая задача 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 года не рекомендует принудительную регулярную смену паролей, так как это подталкивает пользователей к созданию предсказуемых вариаций одного и того же пароля. Вместо этого рекомендуется принудительная смена только при наличии признаков компрометации. Длинный уникальный пароль, хранящийся в менеджере паролей, в сочетании с аутентификацией по SSH-ключам эффективнее, чем 90-дневный цикл смены пароля.

Что делать, если вы потеряли пароль root

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

Все действия ниже требуют использования консоли провайдера, которая в большинстве панелей управления представлена как VNC (virtual network computing) или последовательная консоль. Она подключается к виртуальной машине на уровне ниже сетевого стека, поэтому настройки sshd и правила межсетевого экрана на неё не влияют.

1. Перезагрузите сервер из панели управления и следите за консолью.
2. Откройте меню GRUB. Облачные образы обычно устанавливают GRUB_TIMEOUT=0, поэтому удерживайте Shift при загрузке BIOS или нажимайте Esc несколько раз при загрузке UEFI сразу после начала перезагрузки.
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-образ провайдера, смонтируйте основной диск и измените пароль внутри него.

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 и более новых версиях он обычно находится в отдельном файле в /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 уже есть пароль и вы его забыли, оболочка восстановления запросит его; в этом случае единственный путь — использование образа восстановления провайдера с монтированием диска и выполнением chroot.

Почему passwd выдает ошибку "Authentication token manipulation error"?

Эту ошибку вызывают две причины. Чаще всего это неверный ответ на запрос Current password:, а строка passwd: password unchanged под ним подтверждает, что запись не была выполнена. Вторая причина — файловая система, доступная только для чтения; именно с этим вы сталкиваетесь в режиме восстановления, так как / там смонтирована в режиме read-only. Выполните mount -o remount,rw / и попробуйте снова.

Изменится ли мой пароль sudo при смене пароля Linux?

Да. У 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. и не будет выполнена.