Как изменить пароль root на VPS с Ubuntu

Как изменить пароль root на VPS с Ubuntu

Чтобы изменить пароль root на вашем VPS (виртуальном выделенном сервере) под управлением 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 входить в систему по 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 (непрерывной интеграции). Вместо этого сначала создайте хеш:

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

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