Estou usando o servidor Ubuntu 16.04.3 LTS. Eu tenho um usuário com privilégios sudo. Quando tento mudar do meu usuário atual para root, ele pede minha senha. Eu insiro a senha correta e ela recusa minha senha.
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
Felizmente, tenho outra janela de terminal aberta onde ainda estou logado como root. Então tentei redefinir a senha do meu usuário. Diz que atualizei o usuário com sucesso.
root@server:/# passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Então, tento o sudo sucomando novamente. Ele falha com as mesmas mensagens.
Abro uma nova janela de terminal para o mesmo usuário e tento, sudo sumas o mesmo comando falha com as mesmas mensagens.
Eu também tentei desbloquear o usuário sudo usermod --expiredate -1 username. Isso também não resolveu o problema.
Também tentei conceder direitos "sudo" ao usuário usermod -aG sudo username. E o usuário ainda tinha o problema.
Desisti e criei um novo usuário com direitos sudo e comecei a usar o novo usuário. No dia seguinte comecei a ter exatamente os mesmos problemas com o novo usuário.
O pwckcomando lista várias contas do sistema e mensagens sobre seus diretórios pessoais, mas nada mais. O grpckcomando não fornece nenhuma mensagem.
Recentemente, adicionamos a autenticação "pam" há cerca de um mês.
/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
Graças a @telcoM e @roaima descobri que o módulo de autenticação pam é a causa do problema.
root@server:/# pam_tally2
Login Failures Latest failure From
username 53 06/05/18 16:53:42 xxx.xxx.xxx.xxx
Embora tenha encontrado a causa do problema, não entendo o comportamento. Talvez eu tenha algo configurado incorretamente no módulo pam. Cada vez que digito sudo su(com sucesso ou não), uma falha é adicionada ao arquivo pam_tally2. Não tenho ideia de por que digitar a senha correta com êxito aumentaria as tentativas de falha, mas é. Exemplo abaixo.
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
Usar o sudo -sou sudo -itambém resulta no incremento das falhas no arquivo pam_tally2.
Responder1
Você mencionou que há tentativas contínuas de login de usuários externos não autorizados. Se essas tentativas indesejadas de login remoto fizerem referência rootà sua usernameconta de usuário, isso pode significar que o pam_tally2módulo PAM está bloqueando um ou ambos.
Execute o pam_tally2comando para ver o que está criando as falhas. (Talvez seja necessário executar pam_tally2 --user=username --resetpara redefinir o bloco no username.
Alternativamente, este relatório de problemaO pam_tally2 conta uma senha boa como uma tentativa de login malsucedida se "ChallengeResponseAuthentication yes" estiver definido no arquivo /etc/ssh/sshd_configpode descrever seu cenário mais de perto. (Ainda estou trabalhando para encontrar uma fonte alternativa para uma solução.)
Aliás, apesar de todos os melhores (mas errados) esforços da Canonical, você nunca deveria precisar usar sudo supara nada. (É como dizer "Me dê raiz? OK, obrigado. Agora sou root, preciso me tornar root".) Tente sudo -sum shell root ou sudo -ium shell de login root.