Linux произошла ошибка проверки подлинности

I came across an OS, Minibian, where the setuid bit was missing from /bin/su, causing this error, even if the password of the root account was enabled.

On Linux, the only way to become root is to execute a setuid-root file. When you run sudo or su, their setuid bit is set, so the process’ effective user becomes root, then they do the authentiaction already as root! If it fails they exit.

Anyway, here are the symptoms and the fix:

$ su
Password:
su: authentication failure
$ sudo su
# ls -l /bin/su
-rwxr-xr-x 1 root root 31092 Jun  5  2012 /bin/su
# chmod u+s /bin/su
# ls -l /bin/su
-rwsr-xr-x 1 root root 31092 Jun  5  2012 /bin/su

Note the difference: rwx before, rws after.

• Главная

• Инструкции

• Linux

• Как исправить ошибку аутентификации SSH

Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.

В чем суть ошибки

У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.

Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com. Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы. 

Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю. 

Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:

Permission denied (publickey)

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

Ниже разберемся с наиболее частыми ситуациями. 

Ошибка при использовании пароля

Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:

1. Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
2. Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
3. Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.

С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.

Ошибка при использовании ключей

Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.

Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке: 

Too many authentication failures for user

Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:

ssh -o IdentitiesOnly=yes 
    -o IdentityFile=id1.key 
    user@example.com

Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH ~/.ssh/config. Пример такой настройки:

Host 192.168.3.44
    IdentityFile ~/.ssh/id_rsa
Host *
    IdentitiesOnly=yes

В этом случае SSH будет использовать только идентификаторы, указанные в файлах ssh_config, плюс идентификатор, указанный в командной строке. Идентификаторы, предоставленные агентом, будут игнорироваться.

При использовании ssh-ключей может возникнуть еще одна ошибка:

Permission denied (publickey, password)

Ее причиной может быть ввод неверной ключевой фразы. 

Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.

Восстановление открытого ключа

Если у вас есть закрытый ключ, но вы потеряли открытую часть, то эту проблему можно решить стандартными средствами OpenSSH.

Самый просто способ — использовать утилиту ssh-keygen.

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

ssh-keygen -y -f ~/.ssh/id_rsa

Здесь ~/.ssh/id_rsa — это путь к закрытому части, которая хранится на компьютере. В ответ вы получите последовательность символов. Это и есть открытая часть, которую необходимо добавить на сервер.

В среде Windows решить ту же задачу можно с помощью утилиты PuTTYgen, которая входит в набор PuTTY. В ней есть кнопка Load, через которую вы можете загрузить закрытый ключ. Для этого нужно лишь знать директорию, в которой он хранится на компьютере.

После импорта вы увидите окно с полем `Public key for…`. В нём отобразится открытая часть, которую можно скопировать и отправить на сервер.

Восстановить закрытую часть по открытой нельзя — это противоречит основам безопасности.

На что еще обратить внимание

У понятия «authentication failed» перевод дает весьма общее представление о причине сбоя. Проблема может крыться не только в пароле или ключах. Значение имеют также выставленные права доступа и алгоритмы шифрования.

Неправильная конфигурация клиента 

Распространенная ошибка — использование клиента SSH/SFTP (SSH, PuTTY, Filezilla) без правильной настройки всех необходимых параметров, таких как хост, порт, имя пользователя или закрытый ключ. 

Другая частая проблема возникает, когда вы используете неподдерживаемый сертификат. Например, пытаетесь добавить в PuTTY файл ключа *.pem вместо файла ключа *.ppk.

Противоречия в файле конфигурации

Убедитесь, что в файле /etc/ssh/sshd_config установлены параметры, которые не противоречат друг другу. Такое может быть, например, при отключении парольной проверки или запрете на подключение для пользователя root.

Распространенный пример конфликта: у параметра PasswordAuthentication установлено значение `yes`, а у параметра PermitRootLogin — значение `no` или `without-password`. Из-за этого сервер не понимает, как проверять пользователей, и не пускает никого.

Настройка прав доступа

У OpenSSH строгие правила к тому, кто должен быть владельцем файлов и какие на них должны быть выставлены права доступа.

Убедитесь, что на сервере выставлены следующие доступы:

• ~./ssh – 700.
• ~./ssh принадлежит текущему аккаунту.
• ~/.ssh/authorized_keys – 600.
• ~/.ssh/authorized_keys принадлежит текущему аккаунту.

На клиенте также проверьте разрешения следующих файлов:

• ~ / .ssh / config – 600.
• ~ / .ssh / id_ * – 600.

Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.

Использование устаревших алгоритмов

В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.

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

Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.

Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:

 ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost

Ошибки на сторонних сервисах

Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session. Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.

Заключение

Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.

8 августа 2018 г.

20 октября 2018 г.

slivsol.blogspot

Для всех пользователей IT

Сбой при проверке подлинности Ubuntu

• Получить ссылку
• Facebook
• Twitter
• Pinterest
• Электронная почта
• Другие приложения

Сбой при проверке подлинности Ubuntu

• Получить ссылку
• Facebook
• Twitter
• Pinterest
• Электронная почта
• Другие приложения

Комментарии

Потому что у root нет пароля. Вводить нужно ‘sudo su’

Первый толклвый ответ за сегодня! Про ‘sudo su’ впервые встречаю. Почему-то нигде об этом не говорят.
Спасибо.

А что, если при этом вашего пользователя нет в sudoers file? =) вот как раз столкнулась в этим.

И, кстати, при установке, пароль рутовый указала.. Странно все это..

Класс все работает спс :)))

хотел сносить, ан нет- помучаю ещё!Спасибо!

LinuxMint. Наобновлял всё подряд.
Спасибо, способ помог.

Источник

su: сбой при проверке подлинности

Поставил Debian. Суть проблемы:

su: сбой при проверке подлинности

Если использую sudo:

«username» is not in the sudoers file. This incident will be reported.

Ошибок с паролем быть не может. Как решить?

Решил, всем спасибо. Расходитесь.

Галочка решено и напиши в чем был затык — думаю не один ты столкнулся с такой проблемой, следующий погуглит, попадет на твою тему (лор на первых страницах гугла) и не создаст очередную.

Да пользователя добавить в группу sudo, это же в официальном мануале есть: https://wiki.debian.org/sudo

Так что гугл уже имеет, что выдать. А если человек не привык гуглить — он в любом случае создаст тему.

не создавал для рута пароль?

В таком случае инсталлятор добавляет пользователя в группу автоматически.

И single user mode никто не отменял.

И single user mode никто не отменял.

Я удалял себя из группы судо нечаяно, а пароль рута залочен. Было прикольно. Т.е. single в этом случае тоже не работает.

Я использую команду su.

sudoers

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

С live-cd загрузись и добавь себя в группу sudo, можно редактированием конфигов, можно через chroot.

В том-то все и дело что при установке дестр. Fedora пользователю (2) присаваеваться группа whell и права группы adm. И все работает нормально до поры до времени но в один прекрасный момент ты решаеш открыть файловый менеджер Krusader (с правами root который до этого открывал без проблем ну или что-то другое) и.. спрашивают в окне kde-su пороль root (ввожу Правильный пороль проверяю, жму кнопку продолжить и вот-те здрасте окошко с ошибкой глосящей что у меня (состоящего в групп whell и role adm нет прав запускать приложения с правами root 🙁 🙁 ps Лечиться сей баг лишь только переустановкой пакетов kde-su kf5-su 🙁

Источник

Команда su в Linux

В процессе работы у пользователя часто возникает задача выполнить команду с иными привилегиями. Например, когда он желает установить новую программу, обновить систему, настроить сетевой экран и др. В этом случае ему приходит на помощь команда su в Linux.

Данная команда заменяет пользователя оболочки shell на указанного. Фактически происходит запуск нового экземпляра оболочки с указанными параметрами. Благодаря этому возможно, не выходя из системы, совершенно безболезненно повышать возможности управления операционной системой или наоборот ограничивать их.

Команда su Linux

Команда имеет следующий синтаксис:

su [options] [-] [user]

Если вызов команды происходит без аргументов, то происходит смена пользователя оболочки shell на суперпользователя root. Программа выдаст приглашение ввода пароля, если пароль будет верным, то текущим пользователем станет root.

• options — некоторые дополнительные возможности команды. Мы их рассмотрим ниже:
• [-] — смена контекста выполнения оболочки на контекст указанного пользователя. Переменные $PATH, $HOME, $SHELL, $USER, $LOGNAME содержат значения, характерные для указанного пользователя. Домашняя папка пользователя меняется на другую.
• user — имя пользователя, под которым продолжит работать командная оболочка.

Основные опции команды su:

• -c, —command=command — запускает приложение под указанным аккаунтом;
• -s, —shell=shell— происходит запуск для заданного пользователя указанной оболочки;
• -, -l, —login — смена контекста выполнения на контекст заданного пользователя, аналогична смене пользователя системы для shell;
• -g, —group=group — вызов пользователя, состоящего в заданной группе. Используется только для пользователя root;
• -h, —help — вызов справки для команды.

Далее давайте рассмотрим примеры работы с утилитой su.

Примеры использования su

Смена пользователя на суперпользователя root, без смены окружения оболочки:

Обратите внимание, что здесь вам нужно набрать пароль не своего пользователя, а именно того, от имени которого вы хотите авторизоваться. В данном случае, пользователя root. Если вы получаете ошибку сбой при проверке подлинности su linux, то это может означать, что либо вы ввели пароль неверно, либо пароль для этого пользователя не задан. Такое можно встретить у пользователя root в Ubuntu и Linux Mint. Информацию о том как установить пароль вы можете найти в этой статье. Смена пользователя на суперпользователя root со сменой параметров окружения оболочки:

Смена пользователя на пользователя user01:

Смена пользователя на пользователя user01 со сменой окружения:

Запуск оболочки zsh для пользователя user01:

su -s /usr/bin/zsh user01

Запуск оболочки bash из оболочки zsh для пользователя user01:

su -s /usr/bin/bash user01

Запуск файлового менеджера Midnight Commander для пользователя user01:

Просмотр содержимого директории boot суперпользователем root:

Чтобы выйти из оболочки, открытой командой su можно использовать встроенную команду exit или сочетание клавиш Ctrl+d.

Выводы

Сегодня вы узнали что из себя представляет команда su linux, которая позволяет запустить оболочку от имени другого пользователя, как со сменой окружения, так и без. Узнали как выйти из этой оболочки.

Были рассмотрены различные варианты использования данной команды: для получения прав суперпользователя root, для смены командной оболочки, для выполнения конкретной команды или пакета от имени указанного пользователя.

Источник

Команда su root [Решено]

Что происходит, когда я ввожу su root? Меня просят пароль, но у меня есть только свой пароль (я включён в группу администраторов). Какой пароль я должен ввести в этом случае? Если я ввожу свой пароль (а я единственный пользователь системы), то в результате мне выдаётся сообщение: su: Сбой при проверке подлинности.

И не является ли такое использование команды su ситуацией, непредусмотренной создателями этой команды? Потому что у рута на моей кубунте пароль отсутствует. Пароль есть только у меня как у единственного пользователя системы.

Этот вопрос мне интересен, потому что хотел бы просто для интереса зарегиться под рутом и не использовать sudo. Возможно ли такое?

Рута на kubuntu вообще нету по умолчанию, поэтому у него нету и пароля, поэтому через него и нельзя зайти, поэтому обычно используют sudo -s -H

А вообще про это дело есть в подшивке ТУТ

Команда su открывает сеанс root. Она не требует аргументов, т.е. не надо писать su root. По умолчанию в бунте у root нет пароля, поэтому su не работает.

Чтобы «зарегиться под рутом», выполните sudo passwd root
Открывать сеанс рута без это можно по sudo su или sudo -i

sudo su
Даст тебе желаемое а root в ubuntu по умолчанию отключен — можно конечно включить но сидеть всё время под root-ом плохой тон.

Создать пользователя root это не значит запускать под ним систему. Хотя за многие годы так и не возникла необходимость его создать. Хватало всегда sudo -i

Всегда пользовался sudo bash.
Это не одно и то же?

Как бы не одно и тоже, но результат тот же ))) Тут у каждого свои прибамбасы.

Теперь понятно стало. Я не понимал назначение команды su и команды sudo. Команду sudo может выполнять только пользователь, входящий в группу sudo. А su любой пользователь, и для захода под пользователем нужно знать пароль этого пользователя, под которым заходить надо. Так что su root вообще не нужна из соображений безопасности. Всем спасибо, вы мне просто глаза открыли.

Источник

Проблема с паролём для root

Сегодня установил Fedora 21.Во время установки не указал пароль для root.Теперь когда ввожу команду su — , пишет [apostalig@localhost /]$ su — Пароль: su: Сбой при проверке подлинности

А зачем sudo su , если есть sudo -i или sudo -s или на худой конец sudo bash ?

Если что, пароль рута можно задать, загрузив ядро с параметром init=/bin/bash или подобным

не знаю, man sudo не читал, вообще не люблю эту штуку

Если что, пароль рута можно задать, загрузив ядро с параметром init=/bin/bash или подобным

На какие только извращения ни идут люди, лишь бы не делать sudo passwd .

задать пароль руту?

Может случиться так, что /etc/sudoers не настроен тогда sudo работать не будет. А если и пароль рута не задан, то и su может тоже не работать — тогда иначе никак, похоже. Или с livecd или init=/bin/sh

У меня есть подозрение, что fedora даже не спрашивает пароль рута, как и убунту, по дефолту настраивая sudo.

И спрашивает, и настраивает sudo (если поставить чекбокс «сделать пользователя администратором»).

Юзай sudo -i . Если надо другого юзера – sudo -u username -i , а поскольку у некоторых юзеров бывает false или nologin вместо шелла – sudo -u username /bin/bash . Чтобы задать юзеру пароль – sudo passwd username . У sudo не так и много опций.

Источник

Ошибка Authentication token manipulation error

Для смены паролей пользователей в Linux можно использовать утилиту passwd. Утилита позволяет сменить пароль для текущего пользователя или для любого другого, если у вас есть полномочия суперпользователя. Иногда при попытке смены пароля вы можете получить ошибку Authentication token manipulation error.

В этой статье мы рассмотрим, как исправить её, а также почему она возникает.

Что значит «passwd: Authentication token manipulation error»?

Если переводить дословно, то эта ошибка означает, что утилита для управления паролями passwd не может манипулировать токеном. Под токеном здесь подразумивается хєш пароля, который вы указали. Это может возникнуть из-за невозможности записать новый хэш в файл конфигурации, потому что:

А теперь давайте рассмотрим, как исправить каждую из этих проблем, чтобы убрать ошибку.

Как исправить «Authentication token manipulation error»

1. Права доступа

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

У вас чтение и запись должны быть выставлены как на снимке, если это не так, выполните такую команду:

sudo chmod 0640 /etc/shadow

2. Файловая система только для чтения

Если вы загрузились в режиме восстановления Ubuntu или подобном режиме другого дистрибутива, то по умолчанию файловая система будет находиться в режиме только для чтения, соответственно утилита не сможет ничего записать. Чтобы перемонтировать её для записи, используйте:

3. Модули аутентификации

Ещё одной причиной может быть неправильная настройка модулей аутентификации, из-за которой утилита не может сохранить пароль. Доступные модули можно посмотреть командой:

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

На первом шаге надо нажать Ok:

Затем выбрать с помощью пробела и стрелок нужные модули, переключиться с помощью Tab на Ok и сохранить.

4. Свободное место на диске

Естественно, утилита не сможет изменить пароль, если на диске не будет свободного места. Убедитесь, что есть, как минимум, несколько сотен свободных мегабайт на корневом разделе. Это можно сделать с помощью команды:

А посмотреть, какие файлы занимают больше всего места, и удалить ненужное можно с помощью ncdu:

Если утилита не установлена, то её можно установить с помощью пакетного менеджера. Название пакета такое же как и у команды:

sudo apt install ncdu

5. Ошибки файловой системы

Если файловая система была повреждена, то это тоже может стать причиной проблем с изменением пароля. Для проверки и восстановления файловой системы можно использоваться fsck. Но для работы утилиты файловая система должна быть отмонтирована.

Здесь вместо /dev/sda3 необходимо указать адрес вашего раздела жёсткого диска.

6. Другие решения

Ещё многие советуют перезагрузить систему, возможно, это поможет:

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

А затем установить новый:

sudo passwd имя_пользователя

Выводы

В этой статье мы рассмотрели, как исправить ошибку «passwd: Authentication token manipulation error». Теперь вы знаете, что с ней делать, если она возникнет на вашем компьютере.

Источник

su: сбой при проверке подлинности

Поставил Debian. Суть проблемы:

su: сбой при проверке подлинности

Если использую sudo:

«username» is not in the sudoers file. This incident will be reported.

Ошибок с паролем быть не может. Как решить?

Решил, всем спасибо. Расходитесь.

Галочка решено и напиши в чем был затык — думаю не один ты столкнулся с такой проблемой, следующий погуглит, попадет на твою тему (лор на первых страницах гугла) и не создаст очередную.

Да пользователя добавить в группу sudo, это же в официальном мануале есть: https://wiki.debian.org/sudo

Так что гугл уже имеет, что выдать. А если человек не привык гуглить — он в любом случае создаст тему.

не создавал для рута пароль?

В таком случае инсталлятор добавляет пользователя в группу автоматически.

И single user mode никто не отменял.

И single user mode никто не отменял.

Я удалял себя из группы судо нечаяно, а пароль рута залочен. Было прикольно. Т.е. single в этом случае тоже не работает.

Я использую команду su.

sudoers

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

С live-cd загрузись и добавь себя в группу sudo, можно редактированием конфигов, можно через chroot.

В том-то все и дело что при установке дестр. Fedora пользователю (2) присаваеваться группа whell и права группы adm. И все работает нормально до поры до времени но в один прекрасный момент ты решаеш открыть файловый менеджер Krusader (с правами root который до этого открывал без проблем ну или что-то другое) и.. спрашивают в окне kde-su пороль root (ввожу Правильный пороль проверяю, жму кнопку продолжить и вот-те здрасте окошко с ошибкой глосящей что у меня (состоящего в групп whell и role adm нет прав запускать приложения с правами root 🙁 🙁 ps Лечиться сей баг лишь только переустановкой пакетов kde-su kf5-su 🙁

Источник

Ошибка манипулирования маркером аутентификации

Хорошо, поэтому предложение alexander255 дало работу. Я имел в ЦСТ-TS-L632H-SLIM-8X-DVD диск на моем D830, который я обновление прошивки, связанного здесь:

http://www.dell.com/support/home/us/ ен / 19 / Водители / DriversDetails driverId = R250068 & амп;? FILEID = 2731128725 & амп; osCode = WLH & амп; ProductCode = широта-D830 & амп; LanguageCode = EN & амп; CategoryId = RS

Я использовал основанный апдейтер DOS с моей загрузочную DOS

3 ответа

Я не знаю, как это произошло. Пользователь sudo создал мою учетную запись, затем удалил ее, а затем снова создал.

Показывается пользовательский и зашифрованный пароль.

Ничего не показалось.

Итак, решение было удалить пароль, а затем сбросить новый пароль.

Надеюсь, это поможет.

Я изначально размещал здесь Получение «манипуляции токенами аутентификации» и т. д. ошибка при попытке изменить мой пароль пользователя, но Google показывает этот результат первым, поэтому я повторно опубликовал.

Я получил эту ошибку, изменив пароль на устройстве, где дата не была установлена. (т. е. он был случайным после загрузки)

В основном произошло то, что когда я сменил пароль, незаконная метка времени была обновлена ​​до /etc/shadow. После этого нельзя было использовать эту учетную запись для входа или изменения пароля.

Чтобы исправить учетную запись, я должен был:

Установить правильную дату. Изменить дату истечения срока действия / дату последнего изменения пароля на /etc/shadow (я использовал последний рабочий теневой файл). Смените пароль с правами root на новый.

Эта ошибка исходит от PAM (Pluggable Authentication Module), в котором говорится, что модуль не смог получить новый токен аутентификации (подробнее об этой ошибке читайте в auth.log).

Это связано с ваши настройки авторизации, найденные в каталоге /etc/pam.d/ (например, minimum_uid в common-auth или некоторые другие ограничения, требуемые отметки). Поэтому, пожалуйста, дважды проверьте правильность настроек в модуле PAM.

PAM_AUTHTOK_ERR: модуль был не удалось получить новый токен аутентификации.

Источник

Проблема с паролём для root

Если что, пароль рута можно задать, загрузив ядро с параметром init=/bin/bash или подобным

не знаю, man sudo не читал, вообще не люблю эту штуку

Если что, пароль рута можно задать, загрузив ядро с параметром init=/bin/bash или подобным

задать пароль руту?

Может случиться так, что /etc/sudoers не настроен тогда sudo работать не будет. А если и пароль рута не задан, то и su может тоже не работать — тогда иначе никак, похоже. Или с livecd или init=/bin/sh

У меня есть подозрение, что fedora даже не спрашивает пароль рута, как и убунту, по дефолту настраивая sudo.

И спрашивает, и настраивает sudo (если поставить чекбокс «сделать пользователя администратором»).

Зачем? 20 – стабильнее, 22/23 – свежее.

Поменял имя пользователя этим способом:

А если напрямую в файле /etc/passwd и /etc/shadow поменять имя разве это не будет работать?

Перезагрузил i3wm, и теперь доступ к su запрещен.

А если напрямую в файле /etc/passwd и /etc/shadow поменять имя разве это не будет работать?

Нет, не будет. Меняй обратно

Источник

Исправление ошибки ‘Authentication Token Manipulation Error’ в Ubuntu Linux

Главное меню » Операционная система Ubuntu » Исправление ошибки ‘Authentication Token Manipulation Error’ в Ubuntu Linux

Мы использовали обычную команду passwd, чтобы изменить пароль, и он выдал нам эту ошибку, и пароль не был изменен.

«Authentication Token Manipulation Error’» означает, что по некоторым причинам смена пароля не удалась.

Для этого может быть несколько причин. В простых случаях вы увидите коренную причину проблемы в самом выводе. Например, если вы не указали пароль, вы должны увидеть его в ошибке:

Точно так же, если повторный ввод пароля не совпадает, он также покажет эту информацию:

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

Давайте посмотрим на некоторые из этих случаев и исправим эту проблему.

Способ 1

Вот почему вы должны убедиться, что у вас есть разрешение на чтение и запись в этот файл. Поскольку вы будете изменять пароль как суперпользователь, у этого файла должны быть права на чтение и запись для root.

Если это не так, вы должны установить правильное разрешение:

Способ 2

Метод 1 будет работать в большинстве случаев. Но в нашем случае нам пришлось перемонтировать корневой раздел с правами на чтение и запись. Мы пытались сбросить пароль администратора в Ubuntu.

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

Это сработало для вас?

Мы поделились тем, что сработало для нас, и мы можем только надеяться, что это сработало и для вас. Сделали это? Какой метод работал для вас? Упоминайте это в комментариях.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник