В Linux ошибка Authentication token manipulation error появляется в тот момент, когда система не может сохранить новый пароль. Она возникает при выполнении команды passwd и связана с проблемой записи данных аутентификации: неправильными правами на /etc/shadow, файловой системой в режиме read-only, отсутствием свободного места или ошибкой в конфигурации PAM. Причину можно найти за несколько минут, последовательно проверив четыре пункта, о которых расскажем ниже.

Что означает ошибка Authentication token manipulation error

passwd использует PAM (Pluggable Authentication Modules) для изменения пароля. В стандартной конфигурации Linux данные локальных паролей хранятся в /etc/shadow, а модуль pam_unix работает с /etc/passwd и /etc/shadow для проверки и изменения учетных данных.

Сообщение

passwd: Authentication token manipulation error
passwd: password unchanged

означает, что операция изменения пароля не завершилась успешно.

Важное уточнение: это не обязательно ошибка проверки старого пароля. Пользователь мог ввести текущий пароль правильно, после чего система примет новый пароль, но не сможет записать результат в /etc/shadow.

Так происходит не только при обычном запуске passwd, но и при принудительной смене просроченного пароля во время входа по SSH или через другие программы, использующие PAM. Сам код PAM_AUTHTOK_ERR в Linux/PAM соответствует ошибке Authentication token manipulation error.

Причина 1 — неправильные права на /etc/shadow

Первое, что стоит проверить, — владельца и права файла:

ls -l /etc/shadow

На Debian и Ubuntu стандартный вариант выглядит так:

-rw-r----- 1 root shadow ... /etc/shadow

То есть владелец — root, группа — shadow, права — 640. Debian прямо рекомендует хранить /etc/shadow с владельцем root:shadow и режимом 0640; Ubuntu также использует такую схему

Если значения были изменены, на Debian/Ubuntu их можно восстановить:

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

После этого снова попробуем:

sudo passwd USERNAME

Без проверки не применяем chmod 640 к /etc/shadow на любом Linux-дистрибутиве. В RHEL-подобных системах схема защиты файла может отличаться. Поэтому сначала определяем дистрибутив:

cat /etc/os-release

и сравниваем текущие права с настройками системы.

Ещё стоит проверить целостность файлов учетных записей:

sudo pwck

pwck проверяет структуру /etc/passwd и /etc/shadow, соответствие записей пользователей и корректность полей.

Причина 2 — корневой раздел смонтирован в режиме read-only

Даже если права /etc/shadow правильные, запись невозможна, если файловая система, на которой находится /etc, смонтирована только для чтения.

Проверить режим монтирования можно так:

findmnt /

или:

mount | grep ' on / '

Если в параметрах присутствует ro, корневой раздел работает в режиме read-only. В некоторых ситуациях его можно временно перемонтировать в режим чтения и записи:

sudo mount -o remount,rw /

После этого проверяем:

findmnt /

и повторяем:

sudo passwd USERNAME

Если перемонтирование не выполняется или система снова переводит файловую систему в read-only, не стоит просто многократно повторять команду. Видимо, причина кроется в ошибке файловой системы или в проблемах с диском. И вот тут стоит провести диагностику через recovery/rescue-режим и выполнить проверку файловой системы.

Это в первую очередь касается виртуальных серверов: если SSH перестал работать или система ведет себя нестабильно, полезно иметь альтернативный способ доступа к серверу через панель управления — например, веб-консоль или VNC, если такая функция предусмотрена тарифом и панелью управления.

Причина 3 — на диске не осталось места

Проверить свободное пространство:

df -h

Обращаем внимание на строку с /:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   20G     0 100% /

При заполненном разделе Linux не всегда корректно создает временный файл или запись изменения в системный файл. Сменить пароль в таком случае не удастся, даже при исправном пароле и отсутствии ошибок прав на /etc/shadow.

Если раздел заполнен, сначала найдите крупные каталоги:

sudo du -xhd1 / | sort -h

Часто много места занимают:

  • /var/log — системные журналы;

  • /var/cache"— кэши пакетов и приложений;

  • Docker-образы и контейнеры;

  • старые резервные копии;

  • временные файлы;

  • большие файлы приложений.

Для журналов systemd можно посмотреть их размер:

journalctl --disk-usage

Не удаляйте системные файлы наугад. Первым делом важно определить, что именно заняло диск, освободить немного места и снова попробовать изменить пароль. Если диск на виртуальном сервере постоянно заполняется до 100%, проблема уже не только в passwd. Проверяем размер диска, логи, резервные копии и настройки хранения данных. VPS с большим объемом дискового пространства – как вариант решения проблемы.

Причина 4 — неверная конфигурация PAM

Если права /etc/shadow, файловая система и свободное место в порядке, следующая область проверки — PAM. На Debian и Ubuntu глобальные правила аутентификации находятся в каталоге:

/etc/pam.d/

Правила смены пароля находятся в:

/etc/pam.d/common-password

Конфигурацию смотрим тут:

sudo cat /etc/pam.d/common-password

В Debian-системах для управления стандартными PAM-профилями используется:

sudo pam-auth-update

Утилита управляет профилями PAM, а общие конфигурационные файлы находятся в /etc/pam.d/common-*

Перед ручным изменением конфигурации обязательно делаем резервную копию:

sudo cp /etc/pam.d/common-password /etc/pam.d/common-password.bak

После этого проверяем последние изменения и подключенные PAM-модули.

Не стоит копировать строку из случайного форума и заменять весь common-password. Ошибка в PAM может привести не только к невозможности изменить пароль, но и к проблемам со входом в систему.

На RHEL, CentOS, Rocky Linux и AlmaLinux структура PAM отличается. Там используются другие системные конфигурации, и инструкции для common-password применять напрямую нельзя. Поэтому сначала определяем дистрибутив:

cat /etc/os-release

Если конфигурация PAM была недавно изменена, тогда возвращаем последнюю рабочую версию файла из резервной копии или восстанавливаем конфигурацию средствами самого дистрибутива.

Как быстро определить, какая причина у вас

Диагностируйте проблему от самого простого к более сложному:

  1. Проверяем /etc/shadow. Команда ls -l /etc/shadow. На Debian/Ubuntu ожидается root:shadow и обычно 640.

  2. Проверяем свободное место. Команда df -h. Если / заполнен на 100%, сначала освободите место.

  3. Смотрим режим монтирования. Команда findmnt /.  Если файловая система ro, попробуем sudo mount -o remount,rw /

  4. Проверяем целостность учетных записей командой sudo pwck

  5. Проверяем PAM, если предыдущие пункты не помогли. На Debian/Ubuntu просмотрите /etc/pam.d/common-password

  6. После исправления повторяем смену пароля sudo passwd USERNAME

Такой порядок позволяет лишний раз не менять PAM-конфигурацию и системные файлы.

Если ничего не помогло и доступ по SSH потерян

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

Здесь уже нужен альтернативный доступ к серверу:

  • веб-консоль;

  • VNC/console;

  • serial console;

  • rescue/recovery environment;

  • консоль виртуальной машины на стороне VPS-провайдера.

Через такой канал можно войти непосредственно в систему и проверить /etc/shadow, состояние файловой системы, свободное место и PAM без зависимости от обычного SSH-подключения. Для виртуального сервера это одна из причин заранее выбирать инфраструктуру, где предусмотрен резервный способ администрирования. В панели управления нашего виртуального сервера есть консольный доступ, он особенно полезен именно при ситуациях, когда SSH перестал работать.

Заключение

Authentication token manipulation error — не отдельная загадочная ошибка пароля, а сигнал о том, что операция изменения учетных данных не смогла нормально завершиться. На практике быстрее всего идти по цепочке: права /etc/shadow, свободное место, режим монтирования, RAM.

Сначала проверяются простые и безопасные вещи, затем — файловая система и конфигурация аутентификации. Если SSH уже недоступен, резервный доступ через консоль VPS или другой out-of-band канал позволяет продолжить диагностику непосредственно на сервере.

Для серверов, где важна возможность быстро восстановить доступ, полезно заранее иметь резервный способ администрирования и достаточный запас дискового пространства. VPS с консольным доступом и подходящим объемом хранилища снижает риск оказаться полностью отрезанным от сервера при подобных сбоях.