sudo не запрашивает пароль и сообщает о 3 попытках ввода неверного пароля
Пользователь smithj указан в /etc/sudoers файл:
root ALL=(ALL) ALL
smithj ALL=(ALL) ALL
smithj входит в систему через замазку. Он пытается sudo но получает это:
sudo adduser jonesjp
Sorry, try again.
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
У него никогда не запрашивается пароль. Это на CentOS 6.
Раньше это работало, но другой администратор внес некоторые неизвестные изменения, которые привели к этому, и он недоступен.
5 ответов
Некоторые вещи, чтобы проверить:
Пользователь должен запустить 'sudo -l'. Это просто просит sudo сказать вам, какие разрешения у вас есть. Если вы не можете справиться с этим, существует фундаментальная проблема аутентификации, которая, вероятно, отделена от самого sudo.
Сравните /etc/pam.d/sudo с другими функциональными системами (или резервными копиями).
Сравните /etc/pam.d/system-auth с другими функциональными системами (или резервными копиями). Незначительные изменения в этой системе могут привести к серьезным проблемам при устранении неполадок.
Посмотрите на /etc/pam.d/system-auth и посмотрите, используется ли модуль pam_access.so. Если это так, вы захотите проверить, разрешен ли smithj в /etc/security/access.conf (если другой модуль не указал другой файл). Одна потенциально сложная проблема - если учетной записи разрешен доступ с удаленного IP-адреса, но не локально; это приводит к удаленному входу в систему, но локальные действия, такие как задания cron и аутентификация sudo, не выполняются.
Smithj входит в систему через пароль? Или через ключи? Убедитесь, что они могут войти с паролем, чтобы помочь сузить проблему. Если они нигде не могут успешно использовать свой пароль, начните просматривать изменения в / etc / passwd, / etc / shadow, /etc/nsswitch.conf и любых файлах конфигурации, связанных с каталогом, который вы используете (возможно, ни одного, возможно, LDAP, NIS, AD).
Если у вас запущен демон кэширования, возможно, nscd или sssd, перезапустите демон ('sudo service nscd restart'). Эти демоны печально известны своими проблемами.
У меня была эта проблема на RH Как пользовательская система, файл /etc/pam.d/sudo не существует.
Я просто связываю его с /etc/pam.d/system-auth, и он работает:
root@fws1:~ # ln -s /etc/pam.d/system-auth /etc/pam.d/sudo
Проверьте свои /etc/pam.conf файл. чтобы исправить мои проблемы, я должен был добавить
#############################
# SUDO service
#############################
sudo auth required pam_authtok_get.so
sudo auth required pam_dhkeys.so
sudo auth sufficient pam_unix_auth.so
sudo auth required pam_login_auth.so
sudo account required pam_roles.so
sudo account required pam_projects.so
sudo account required pam_unix_account.so
sudo account required pam_login_auth.so
Проверьте /etc/nsswitch.conf файл для sudoers: files а затем проверьте /etc/passwd а также /etc/shadow для учетной записи пользователя.
У меня был настроен LDAP, и пользователь не существовал в локальных файлах, следовательно, ошибка, поскольку сервер искал в LDAP для аутентификации.
Настройка Sudo и LDAP - это совершенно другая тема.
У меня была похожая проблема при компиляции sudo для Linux с нуля 7.9. Если pam не установлен должным образом, мне пришлось перекомпилировать sudo --without-pam. Так что я решил проблему, это, безусловно, в безопасности.