Debian/Ubuntu: sudo: unable to change expired password при входе по SSH — как исправить

Ошибка sudo: unable to change expired password в Debian и Ubuntu почти всегда возникает в самый неудобный момент: вы подключаетесь по SSH, вводите пароль, система вроде бы пускает, но дальше не дает выполнить sudo, сменить пароль штатным способом или вообще завершить авторизацию. В логах и на экране могут встречаться близкие формулировки: You are required to change your password immediately, Password expired, passwd: Authentication token manipulation error, Account expired. Снаружи это выглядит как проблема с sudo, но на практике причина обычно находится на стыке сроков действия пароля, политики PAM, настроек SSH и состояния самой учетной записи.

Хорошая новость в том, что в большинстве случаев ситуацию можно исправить без переустановки системы. Плохая — если действовать вслепую, легко потерять последний рабочий доступ, особенно на удаленном сервере без консоли. Поэтому ниже разберем не только команды, но и логику диагностики: что именно истекло, почему обычная смена пароля не срабатывает, как безопасно восстановить доступ и что проверить после исправления.

Эта инструкция подойдет для типичных сценариев:

• при входе по SSH система требует сменить пароль, но не дает этого сделать;
• sudo отказывает с сообщением про истекший пароль;
• учетная запись пользователя не просрочена целиком, но срок действия пароля уже вышел;
• после изменений в PAM, SSH или политике паролей начались проблемы с логином;
• на сервере есть доступ через root, консоль гипервизора или rescue-режим, и нужно быстро вернуть рабочий вход обычному пользователю.

Что означает эта ошибка на самом деле

В Linux есть несколько разных «сроков годности» учетной записи, и это важно. Администратор часто говорит, что «пароль протух», но система различает как минимум три состояния:

• истек срок действия самого пароля;
• истек срок действия учетной записи целиком;
• пароль нужно сменить при следующем входе, даже если формально он еще не просрочен.

Эти параметры обычно хранятся в /etc/shadow. Именно оттуда команды passwd, chage, PAM-модули и SSH понимают, можно ли пользователю войти, обязан ли он сменить пароль и есть ли у него на это право в текущем контексте.

Ошибка sudo: unable to change expired password обычно появляется, когда пользователь уже прошел часть аутентификации, но дальше система пытается инициировать обязательную смену пароля — и этот процесс ломается. На практике это происходит по одной из причин:

• вход по SSH разрешен, но интерактивная смена пароля через PAM не проходит;
• в PAM-стеке отсутствует нужный модуль или нарушен порядок правил;
• у пользователя нет нормального TTY или псевдотерминала;
• учетная запись заблокирована или истекла целиком, а не только пароль;
• команда passwd не может обновить /etc/shadow из-за прав, readonly-rootfs или проблем с файловой системой;
• SSH настроен так, что смена просроченного пароля не может завершиться корректно.

Самая частая ошибка в диагностике — лечить только sudo. В большинстве случаев sudo лишь сообщает о более глубокой проблеме: пароль истек, а механизм его смены в текущей сессии не работает.

С чего начать, чтобы не потерять доступ

Если у вас уже открыта хотя бы одна рабочая сессия на сервере, не закрывайте ее, пока не убедитесь, что новый вход действительно работает. Это простое правило часто спасает от лишней загрузки в rescue или восстановления через панель провайдера.

Если обычный SSH-вход сломан, безопасные варианты доступа обычно такие:

• войти под root, если root по SSH разрешен и у вас есть пароль или ключ;
• подключиться через VNC или Serial-консоль в панели управления сервером;
• загрузиться в recovery или rescue-режим;
• использовать вторую привилегированную учетную запись, если она есть.

Если у вас нет альтернативного способа доступа, сначала организуйте его, и только потом меняйте PAM, SSH или атрибуты пароля. Для удаленных машин на VDS это особенно важно: ошибка в конфиге может мгновенно оставить сервер без админского входа.

Если вы как раз планируете переносить проекты на отдельный сервер и хотите заранее продумать аварийный доступ, пригодится материал про миграцию с виртуального хостинга на VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проверяем, что именно истекло

Первое, что нужно сделать от имени root, — посмотреть статус проблемного пользователя. Удобнее всего начать с chage:

chage -l username

Вывод обычно выглядит примерно так:

Last password change                    : Apr 10, 2026
Password expires                        : Apr 11, 2026
Password inactive                       : never
Account expires                         : never
Minimum number of days between password change : 0
Maximum number of days between password change : 1
Number of days of warning before password expires : 7

Здесь нас особенно интересуют строки Password expires и Account expires. Если истек только пароль, восстановление обычно простое. Если истекла вся учетная запись, придется отдельно продлить срок действия аккаунта.

Дополнительно полезно проверить запись в /etc/shadow:

grep '^username:' /etc/shadow

Разбирать поле вручную не всегда удобно, но эта команда помогает понять, не заблокирован ли пароль, существует ли shadow-запись и не выглядит ли она поврежденной.

Также проверьте, действительно ли sudo упирается именно в пароль, а не в отсутствие прав:

sudo -l

Если команда даже не запускается и сразу возвращает ошибку про expired password, направление диагностики выбрано верно.

Быстрое исправление от root: новый пароль и корректные атрибуты

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

Сначала установите новый пароль:

passwd username

Затем проверьте статус еще раз:

chage -l username

Если системе по-прежнему кажется, что пароль нужно сменить немедленно, можно обновить дату последней смены:

chage -d $(date +%F) username

Если у учетной записи истек общий срок действия, снимите его:

chage -E -1 username

Если проблема была связана именно с истекшим паролем, после этих команд пользователь обычно снова может входить по SSH и использовать sudo.

Когда лучше не использовать принудительную просрочку сразу

Администраторы нередко применяют такую команду:

passwd -e username

Она принудительно делает пароль просроченным и заставляет пользователя сменить его при следующем входе. Для локальной машины это нормально. Но на удаленном сервере с нестандартным PAM или ограниченным SSH-окружением именно такой сценарий часто и порождает ошибку, которую мы разбираем.

Если сервер критичный, сначала убедитесь, что интерактивная смена пароля через SSH действительно работает, и только потом используйте passwd -e в автоматизации.

Если истекла не только парольная фраза, но и сама учетная запись

Здесь важно не перепутать два разных случая. Пользователь может иметь рабочий пароль, но учетная запись уже недействительна по календарной дате. Тогда смена пароля сама по себе не поможет.

Проверьте это так:

chage -l username

Если строка Account expires содержит прошедшую дату, снимите ограничение:

chage -E -1 username

Либо установите новую дату окончания:

chage -E 2026-12-31 username

После этого еще раз убедитесь, что пароль не заблокирован:

passwd -S username

Типичный нормальный статус — P, то есть usable password. Если видите блокировку, проверьте, не применялась ли команда passwd -l и не менялся ли вручную хеш в /etc/shadow.

Почему SSH не дает сменить просроченный пароль

Даже когда сама учетная запись в порядке, смена просроченного пароля может ломаться именно в SSH-сеансе. Обычно стоит проверить несколько узких мест.

Параметр UsePAM

В Debian и Ubuntu для нормальной работы парольной аутентификации и обязательной смены пароля через SSH обычно нужен включенный PAM:

grep -E '^(UsePAM|PasswordAuthentication|KbdInteractiveAuthentication|ChallengeResponseAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

На что смотреть в первую очередь:

• UsePAM yes — обычно обязательно;
• PasswordAuthentication yes — нужно, если вход паролем вообще разрешен;
• в новых версиях OpenSSH вместо ChallengeResponseAuthentication чаще используют KbdInteractiveAuthentication.

Если установлено UsePAM no, система может аутентифицировать пользователя, но не выполнить сценарий обязательной смены просроченного пароля как положено.

После изменения конфигурации проверьте синтаксис:

sshd -t

И только потом перечитывайте сервис:

systemctl reload ssh

systemctl reload sshd

PAM-стек для SSH и passwd

Если недавно редактировались файлы в /etc/pam.d/, вполне возможно, что сломалась именно логика обработки просроченного пароля. Обычно стоит проверить как минимум:

• /etc/pam.d/sshd;
• /etc/pam.d/common-auth;
• /etc/pam.d/common-account;
• /etc/pam.d/common-password;
• /etc/pam.d/sudo;
• /etc/pam.d/passwd.

На Debian и Ubuntu особенно важно, чтобы в common-password был рабочий модуль pam_unix.so, а в account-цепочке корректно отрабатывались проверки срока действия. Если PAM уже меняли после экспериментов с LDAP, SSSD, 2FA или нестандартными модулями, смена пароля может обрываться без понятного сообщения для пользователя.

Посмотреть свежие ошибки удобно так:

journalctl -u ssh -n 100 --no-pager

journalctl -xe --no-pager

grep -iE 'pam|passwd|shadow|expired|account' /var/log/auth.log

Ищите формулировки вроде PAM account management error, Authentication token manipulation error, Password change failed, User account has expired.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Если passwd не может обновить /etc/shadow

Иногда сообщение про expired password — лишь верхушка айсберга, а реальная причина в том, что система не может записать новые данные в shadow-файл. Тогда пользователь вроде бы должен сменить пароль, но технически это невозможно.

Проверьте базовые вещи:

mount | grep ' on / '

df -h /

df -i /

ls -l /etc/shadow /etc/passwd

На практике здесь чаще всего всплывает одна из проблем:

• корневая файловая система смонтирована в режиме только для чтения;
• на диске закончилось место;
• закончились inode;
• права или владелец у /etc/shadow повреждены;
• файловая система выдала ошибки и ушла в защитный режим.

Обычные права на /etc/shadow в Debian и Ubuntu выглядят так:

chmod 640 /etc/shadow
chown root:shadow /etc/shadow

Но прежде чем что-то чинить вручную, лучше сравнить состояние с заведомо рабочей системой или резервной копией. Бездумная правка прав на системные файлы часто создает уже вторую проблему поверх первой.

Если вы обслуживаете несколько проектов и решаете, где держать такие системы — на виртуальном хостинге или на отдельном сервере, — полезно заранее понимать, какой уровень доступа к консоли и recovery вам действительно нужен.

Что делать, если root-доступа нет, а есть только проблемный пользователь

Тут сценариев меньше. Если пользователь может войти по SSH и получает приглашение сменить пароль, попробуйте открыть полноценную интерактивную сессию с TTY. Иногда вход ломается не из-за самого пароля, а потому что клиент не выделяет терминал корректно.

ssh -t username@server

Если у вас уже есть сессия, попробуйте запустить:

passwd

Но если система сразу отвечает ошибкой или разрывает сеанс, без root, консоли или rescue-доступа дальше обычно не пройти. В этом случае практический путь только один: получить административный доступ через панель виртуальной машины, аварийный режим или помощь другого администратора.

Если вы администрируете удаленные серверы, держите хотя бы один независимый канал доступа: root по ключу через консоль, отдельного break-glass пользователя или аварийный вход через панель управления.

Проверка после исправления

Когда вы сбросили пароль или обновили срок действия учетной записи, не ограничивайтесь одной успешной командой. Нужно убедиться, что проблема решена целиком.

Минимальный чек-лист такой:

1. Откройте новую SSH-сессию и войдите проблемным пользователем.
2. Проверьте, что вход проходит без требования немедленной смены пароля, если вы этого не планировали.
3. Выполните sudo -l и обычную команду через sudo.
4. Проверьте chage -l username.
5. Просмотрите последние записи в auth.log или journald.

Если после сброса пароля пользователь входит, но sudo все еще жалуется, отдельно проверьте PAM-конфигурацию для sudo:

sudo -V

И сопоставьте результат с файлами /etc/pam.d/sudo и /etc/pam.d/common-*. Иногда проблема уже не в истекшем пароле, а в некорректной PAM-цепочке именно для sudo.

Как не допустить повторения

Большинство таких инцидентов происходят не потому, что истечение пароля само по себе плохо, а потому, что политика паролей включена без учета реального способа администрирования серверов. Если у вас доступ по SSH-ключам, CI/CD, служебные аккаунты и автоматизация, принудительная смена паролей может принести больше проблем, чем пользы.

Практические рекомендации:

• не используйте passwd -e массово на прод-серверах без проверки сценария SSH и PAM;
• для админских аккаунтов чаще опирайтесь на SSH-ключи, а не на часто истекающие пароли;
• не тестируйте изменения в /etc/pam.d/ на единственном рабочем аккаунте;
• держите второй root-канал доступа через консоль или аварийного пользователя;
• перед включением политики истечения проверьте значения PASS_MAX_DAYS, PASS_MIN_DAYS и PASS_WARN_AGE в /etc/login.defs;
• после правок SSH всегда запускайте sshd -t и держите открытую текущую сессию до проверки нового входа;
• мониторьте ошибки аутентификации и события PAM в логах.

Если вы параллельно настраиваете окружение для сайтов и сервисов, полезно отдельно продумать безопасную схему обновлений и тестирования. Для этого может пригодиться статья про staging и DNS-схему для проектов на VDS.

Короткий runbook для быстрого восстановления

Если нужен короткий рабочий сценарий, то в типовом случае порядок действий такой:

1. Получить root-доступ через рабочую сессию, консоль или rescue.
2. Проверить статус пользователя: chage -l username.
3. Задать новый пароль: passwd username.
4. Обновить дату смены пароля: chage -d $(date +%F) username.
5. Если истек аккаунт целиком — снять срок: chage -E -1 username.
6. Если проблема повторяется — проверить SSH и PAM: UsePAM, PasswordAuthentication, логи auth.log и journald.
7. Открыть новую SSH-сессию и проверить sudo.

В большинстве случаев этого достаточно. Если не помогло, причина уже почти наверняка в PAM, повреждении системных файлов, корневой файловой системе только для чтения или неочевидных ограничениях среды — например, в контейнере, chroot, rescue-окружении или кастомной схеме аутентификации.

Итог

Сообщения вида unable to change expired password, sudo unable to change expired password и ssh password expired означают не одну конкретную поломку, а целый класс проблем вокруг срока действия пароля и механизма его смены. Быстрее всего исправляется ситуация, когда у вас есть root-доступ и истек только пароль: достаточно задать новый пароль и обновить дату его смены. Сложнее случаи, где замешаны PAM, SSH, readonly-rootfs или просроченная учетная запись целиком.

Главный практический вывод простой: сначала уточняйте, что именно истекло, потом восстанавливайте доступ самым коротким и безопасным маршрутом, и только после этого разбирайтесь, почему штатная смена пароля не сработала. Для удаленных Debian и Ubuntu серверов это заметно безопаснее, чем пытаться лечить проблему прямо из полусломанной SSH-сессии.