
Я использую Ubuntu 16.04.3 LTS Server. У меня есть пользователь с привилегиями sudo. Когда я пытаюсь переключиться с текущего пользователя на root, он запрашивает мой пароль. Я ввожу правильный пароль, но он отклоняет мой пароль.
username@server:/ sudo su
[sudo] password for username:
Sorry, try again.
[sudo] password for username:
Sorry, try again.
[sudo] password for username:
sudo: 3 incorrect password attempts
К счастью, у меня открыто другое окно терминала, в котором я все еще вошел как root. Поэтому я попытался сбросить пароль для своего пользователя. Он говорит, что я успешно обновил пользователя.
root@server:/# passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Поэтому я снова пытаюсь выполнить sudo su
команду. Она терпит неудачу с теми же сообщениями.
Я открываю новое окно терминала для того же пользователя и пытаюсь выполнить sudo su
ту же команду, но она завершается ошибкой с теми же сообщениями.
Я также попробовал разблокировать пользователя sudo usermod --expiredate -1 username
. Это также не решило проблему.
Я также пробовал предоставить пользователю права "sudo" usermod -aG sudo username
. И у пользователя все еще была проблема.
Я сдался и просто создал нового пользователя с правами sudo и начал использовать нового пользователя. На следующий день у меня начались те же самые проблемы с новым пользователем.
Команда pwck
выводит список нескольких системных учетных записей и сообщений об их домашних каталогах, но больше ничего. Команда grpck
не выдает никаких сообщений.
Около месяца назад мы добавили аутентификацию «pam».
/etc/pam.d/sudo
#%PAM-1.0
session required pam_env.so readenv=1 user_readenv=0
session required pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive
/etc/pam.d/common-auth
auth required pam_tally2.so deny=5 unlock_time=600
# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config
/etc/pam.d/common-account
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
/etc/pam.d/common-session-noninteractive
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
# end of pam-auth-update config
Благодаря @telcoM и @roaima я обнаружил, что причиной проблемы является модуль аутентификации pam.
root@server:/# pam_tally2
Login Failures Latest failure From
username 53 06/05/18 16:53:42 xxx.xxx.xxx.xxx
Хотя я нашел причину проблемы, я не понимаю ее поведение. Возможно, я что-то неправильно настроил в модуле pam. Каждый раз, когда я печатаю sudo su
(успешно или нет), в pam_tally2
. Я понятия не имею, почему успешный ввод правильного пароля увеличивает количество неудачных попыток, но это так. Пример ниже.
pam_tally2
Login Failures Latest failure From
username 0 06/05/18 16:53:42 xxx.xxx.xxx.xxx
username@server:/ sudo su
[sudo] password for username:
root@server:/#
pam_tally2
Login Failures Latest failure From
username 1 06/05/18 16:54:03 xxx.xxx.xxx.xxx
Использование sudo -s
или sudo -i
также приводит к увеличению количества сбоев в pam_tally2
.
решение1
Вы упомянули, что существуют постоянные попытки входа от неавторизованных внешних пользователей. Если эти нежелательные попытки удаленного входа ссылаются root
на вашу username
учетную запись пользователя, это может означать, что pam_tally2
модуль PAM блокирует одну или обе из них.
Запустите pam_tally2
команду, чтобы увидеть, что создает сбои. (Возможно, вам придется запустить команду, pam_tally2 --user=username --reset
чтобы сбросить блокировку на username
.
В качестве альтернативы, этот отчет о проблемеpam_tally2 считает хороший пароль неудачной попыткой входа в систему, если в файле /etc/ssh/sshd_config установлено значение «ChallengeResponseAuthentication yes»может описать ваш сценарий более точно. (Я все еще работаю над поиском альтернативного источника решения.)
Кстати, несмотря на все лучшие (но неправильные) усилия Canonical, вам никогда не придется использовать sudo su
для чего-либо. (Это как сказать "Дайте мне root? Хорошо, спасибо. Теперь я root, мне нужно стать root".) Попробуйте sudo -s
использовать оболочку root или sudo -i
оболочку входа root.