Estoy usando el servidor Ubuntu 16.04.3 LTS. Tengo un usuario con privilegios sudo. Cuando intento cambiar de mi usuario actual a root, me pide mi contraseña. Ingreso la contraseña correcta y rechaza mi contraseña.
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
Afortunadamente, tengo otra ventana de terminal abierta donde todavía estoy conectado como root. Entonces intenté restablecer la contraseña de mi usuario. Dice que he actualizado al usuario correctamente.
root@server:/# passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Entonces intento ejecutar el sudo sucomando nuevamente. Falla con los mismos mensajes.
Abro una nueva ventana de terminal para el mismo usuario, lo intento sudo suy el mismo comando falla con los mismos mensajes.
También intenté desbloquear al usuario sudo usermod --expiredate -1 username. Esto tampoco resolvió el problema.
También intenté otorgarle al usuario derechos "sudo" usermod -aG sudo username. Y el usuario todavía tenía el problema.
Me di por vencido y simplemente creé un nuevo usuario con derechos sudo y comencé a usar el nuevo usuario. Al día siguiente comencé a tener exactamente los mismos problemas con el nuevo usuario.
El pwckcomando enumera varias cuentas del sistema y mensajes sobre sus directorios personales, pero nada más. El grpckcomando no da ningún mensaje.
Recientemente agregamos la autenticación "pam" hace aproximadamente un mes.
/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/cuenta-común
# 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
Gracias a @telcoM y @roaima descubrí que el módulo de autenticación pam es la causa del problema.
root@server:/# pam_tally2
Login Failures Latest failure From
username 53 06/05/18 16:53:42 xxx.xxx.xxx.xxx
Si bien encontré la causa del problema, no entiendo el comportamiento. Quizás tengo algo configurado incorrectamente en el módulo pam. Cada vez que escribo sudo su(con éxito o no), se agrega un error al archivo pam_tally2. No tengo idea de por qué escribir correctamente la contraseña correcta incrementaría los intentos fallidos, pero lo es. Ejemplo a continuación.
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
El uso de sudo -so sudo -itambién da como resultado un incremento de las fallas en el archivo pam_tally2.
Respuesta1
Mencionaste que hay continuos intentos de inicio de sesión por parte de usuarios externos no autorizados. Si estos intentos de inicio de sesión remoto no deseados hacen referencia roota su usernamecuenta de usuario, puede significar que el pam_tally2módulo PAM está bloqueando uno o ambos.
Ejecute el pam_tally2comando para ver qué está creando las fallas. (Es posible que tengas que ejecutar pam_tally2 --user=username --resetpara restablecer el bloqueo en username.
Alternativamente, este informe de problemapam_tally2 cuenta una buena contraseña como un intento fallido de inicio de sesión si "ChallengeResponseAuthentication yes" está configurado en el archivo /etc/ssh/sshd_configpuede describir su escenario más de cerca. (Todavía estoy trabajando para encontrar una fuente alternativa para una solución).
Por cierto, a pesar de todos los mejores (pero incorrectos) esfuerzos de Canonical, nunca deberías necesitar usarlo sudo supara nada. (Es como decir "¿Dame raíz? Está bien, gracias. Ahora soy root, necesito convertirme en root".) Pruebe sudo -scon un shell raíz o sudo -iun shell de inicio de sesión raíz.