Ubuntu Server не може змінити паролі

В даний час я працюю з довірою (Ubuntu 14.04.3 LTS) з версією ядра 3.13.0-65-generic.

Як корінь я не можу змінювати пароль користувача:

 root@server:~# passwd newuser
 passwd: Authentication token manipulation error
 passwd: password unchanged

Я також не можу змінити пароль для самого облікового запису root:

root@server:~# passwd
passwd: Authentication token manipulation error
passwd: password unchanged

Я шукав деякий час. Це не є проблемою з / необхідно встановлювати як r / w. Дозволи на / etc / passwd та / etc / shadow - це добре. Я можу вручну змінити пароль у файлі / etc / shadow і це працює. Але мені потрібно зрозуміти, чому passwd отримує помилку.

Я думаю, що мені потрібно глибше копатися в /etc/pam.d/*, але я не впевнений, з чого почати.

Будь-які ідеї будуть дуже вдячні. Дякую!

ОНОВЛЕНА ІНФОРМАЦІЯ:

У командному рядку не передаються сторонні символи.
В даний час це питання для всіх існуючих і нових користувачів, я спробував додати нового користувача з adduser і отримав ту ж помилку з скрипта adduser, коли він повинен був запитати мене про пароль.

— Plazgoth
джерело

passwd <user> передбачається запросити новий пароль користувача, а потім повторити перевірку. Те, що ви вставили, схоже, що ви, можливо, включаєте сторонні символи після імені користувача. У вас є пробіл після імені користувача? Чи має / var / log / secure або / var / log / messages інші підказки? Це лише для цього користувача? Якщо ви створюєте user2, це відбувається для них?

— Xalorous

Дякуємо за ідеї. Я оновив оригінальне запитання з деякими відповідями на ваші запитання і подивимося на журнали, які ви згадали далі.

— Plazgoth

Можливо, перевірити профіль bash для псевдонімів для пароля, які додають елементи? Я не знаю Ubuntu, тому я не можу сказати вам, де шукати. На RHEL, це ~/.bashrc і ~/.bash_profile. І якщо у вас немає такої, то вона дає вам /etc/.bashrc і /etc/.bash_profile. І не забувайте, корінь ~ є /root/, не /user/username. Також спробуйте sudo passwd username з користувачем з правами sudoer.

— Xalorous

Дякуємо за пропозиції. Можна перевірити наявність псевдонімів із самою командою псевдоніма, не шукаючи скриптів запуску. Псевдонім сам по собі дає псевдоніми поточного користувача. Я також намагався використовувати sudo безрезультатно. Нічого цікавого у журналах ви не згадали.

— Plazgoth

Перевірте право власності та дозволи на файл / etc / shadow. Якщо хтось інший є власником, а «інший» біт не містить «запису», це може призвести до цього. І це виходить за межі мого досвіду щодо того, як це припинити, але якщо біт setuid для команди passwd не встановлено, або щось маскує його, це призведе до того, що інші не зможуть встановити passwd, але root все ще може. Але корінь також не працює.

— Xalorous

Відповіді:

Ok я думаю я маю це рахував. Викопавши /etc/pam.d/*, увімкнув параметри налагодження та аудиту для більшості звичайних файлів. Це не допомогло багато чого, крім того, щоб вказати на модуль pam_unix:

passwd[45463]: pam_unix(passwd:chauthtok): username [root] obtained
passwd[45463]: pam_unix(passwd:chauthtok): username [root] obtained
passwd[45463]: pam_unix(passwd:chauthtok): password - new password not obtained

Я почав більш уважно дивитися на кожну з опцій у загальному паролі, наданому pam_unix.so. Варіанти, які я мав, були: незрозуміле використання_автохт try_first_pass sha512

Читання чоловічої сторінки для pam_unix я побачив, що use_authtok пов'язано зі зміною пароля. І він говорив про використання його після pam_cracklib. У моєму випадку немає pam_cracklib, тому я вирішив спробувати видалити цей варіант. Це повністю відновило функціональність команди passwd.

Я не впевнений, що сценарій додав цей параметр або він був за замовчуванням.

Дякуємо всім, хто намагався надати ідеї.

— Plazgoth
джерело

Здається, проблема пов'язана з encryptfs (зашифрованим модулем файлової системи pam). Коли користувач змінює свій пароль, парольну фразу шифрування диска потрібно якось змінити. Коли ця спроба зміни не вдасться, процес зміни пароля завершується невдало і відновлюється. Подивитися: https://bugs.launchpad.net/ecryptfs/+bug/1486470

— DrNoone
джерело

Дякуємо за пропозицію. У загальнодоступних файлах ecryptfs був встановлений як необов'язковий, не обов'язковий, тому я пішов вперед і прокоментував його. Це привело до того, що WARNING перестане з'являтися в /var/log/auth.log. Проте, це не вирішило проблеми команди passwd, яка не працює. На даний момент навіть увійти в систему як root Я не можу запустити команду passwd для зміни пароля root.

— Plazgoth