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

Как изменить пароль 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 минут в Ubuntu). Этот интервал отсчитывается не от последнего ввода команды, так как sudo -v обновляет кэшированные данные без повторного запроса. Таким образом, новый пароль пройдёт первую реальную проверку только тогда, когда 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 продолжает работать, так как аутентификация по открытому ключу не проверяет хеш пароля. Чтобы полностью заблокировать учетную запись, установите срок её действия:

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 (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, начиная с 18.04, чего нельзя сказать о chpasswd -c YESCRYPT: более старый пакет shadow в версии 20.04 не распознает этот метод. Исключением является Ubuntu 16.04, так как в её OpenSSL 1.0.2 вообще отсутствует опция -6. Эти хеши сохраняются и при обновлении версии ОС, поэтому перенос сервера с 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 устанавливает дату последней смены пароля на начало эпохи, поэтому PAM считает пароль просроченным. При следующем интерактивном входе система запросит текущий пароль, а затем новый, прежде чем предоставить доступ к оболочке. sudo passwd -e deploy выполняет точно такое же действие.

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

Password change required but no TTY available.

Удаленная команда не выполняется, и ssh завершается с ненулевым кодом возврата. Если вызывающий скрипт не останавливается при возникновении ошибок с помощью set -e или явной проверки, последующие строки продолжат выполняться, и задача может завершиться так, будто перезапуск был выполнен успешно.

Что означают поля старения пароля

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. Этот no может находиться как в основном файле, так и во вспомогательном (drop-in), поэтому проверьте оба. sshd считывает файлы в /etc/ssh/sshd_config.d/ в начале конфигурации и сохраняет первое найденное значение для каждого параметра, поэтому вспомогательный файл переопределяет /etc/ssh/sshd_config. Это же правило часто работает в обратную сторону на серверах Ubuntu 24.04, установленных с ISO-образа с включенным SSH: установщик оставляет файл cloud-init 50-cloud-init.conf, который задает PasswordAuthentication yes, и параметр no, добавленный в основной файл, игнорируется. Проверьте эффективные значения:

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 / и попробуйте снова.

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

Да. sudo не имеет собственного пароля. Он аутентифицирует вас через PAM по той же записи в /etc/shadow, которую используют SSH и su, поэтому на каждую учетную запись приходится один пароль. Именно поэтому первый запрос sudo после смены пароля является настоящей проверкой. Выполните sudo -k && sudo -v, чтобы вызвать этот запрос, пока у вас еще есть активная сессия.

Нарушит ли смена пароля работу моих SSH-ключей или открытых сессий?

Смена пароля или passwd -l — нет. Аутентификация по открытому ключу не проверяет хеш пароля, поэтому ключи продолжают работать в обоих случаях. chage -d 0 работает иначе: sshd выполняет проверки учетной записи PAM даже после входа по ключу, и эти проверки считывают поля срока действия пароля в /etc/shadow. Поэтому просроченный пароль заставит систему требовать новый пароль даже при входе по ключу, а скриптовые SSH-команды завершатся ошибкой. Уже открытые сессии остаются активными, так как SSH проверяет учетные данные только в момент входа. Единственное, что изменится внутри активной сессии — sudo, который запросит новый пароль после истечения 15-минутного тайм-аута.

Как заставить пользователя сменить пароль при следующем входе?

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