Questão Sudo não reconhece mais minha senha


  • O problema está acontecendo em um servidor remoto, então tudo é feito através de ssh.
  • Eu posso entrar com a minha chave, não há problema aqui.
  • Eu posso mudar minha senha à vontade com passwd (o que acredito mostra que é a senha correta para o meu usuário).
  • Meu usuário está no arquivo sudoers (eu poderia verificar com pkexec cat /etc/sudoers e digitando a senha do root)

No entanto, sendo logado como meu usuário regular, não posso correr sudo comandos mais, apenas diz Sorry, try again como se a senha fosse digitada incorretamente.

Eu não tenho idéia do que causa isso, eu tentei mudar minha senha, o que pude, mas não resolve o problema sudo problema.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.10
Release:        12.10
Codename:       quantal

1
2017-12-28 10:42


origem


Você é o administrador do servidor remoto? É possível que alguém tenha mudado o módulo do PAM que o sudo usa para autenticar seus usuários e que, seja lá o que estiver definido, seja diferente do sistema que o passwd está usando para autenticação. Você pode usar isso ao configurar senhas diferentes para o sudo e para o login do shell. - Aaron D


Respostas:


Ok, consertei, mas eu realmente não sei o que causou isso em primeiro lugar.

A questão era de uma linha em /etc/pam.d/common-session-noninteractive

Tinha

session [success=1 default=ignore] pam_succeed_if.so service in cron 
quiet use_uid

E parece que ter isso em duas linhas, em vez de em uma, estava quebrando completamente o PAM. Eu apenas mudei para

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

E agora tudo está de volta ao normal.

Tenho que agradecer a @AaronD pelo seu comentário, pois me indicou a investigar o PAM, que não encontrei nada de errado no início (olhando para /etc/pam.d/sudo) mas quando eu olhei /var/log/auth.log e notei todos os erros do PAM que senti que estava cavando na direção certa.

A entrada de log se parecia com isso:

Dec 28 15:43:33 srv12120 sudo: PAM (sudo) illegal module type: quiet
Dec 28 15:43:33 srv12120 sudo: PAM pam_parse: expecting return value; [...use_uid]
Dec 28 15:43:33 srv12120 sudo: PAM (sudo) no module name supplied

Um pouco de googling me deu este post no fórum o que me deu a solução destacada acima.


2
2017-12-28 15:01





Recentemente encontrei esse problema exato, por meio de uma solução um pouco diferente. A causa foi muito parecida.

Basicamente, no meu caso, de alguma forma, /etc/pam.d/common-session-noninteractive tinha ficado ligeiramente corrompido de uma maneira bastante bizarra. Minhas common-session-noninteractive ficou assim:

# 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)
Dec 25 11:45:01 websrv CRON[44085]: pam_unix(cron:session): session opened for user root by (uid=0) session 
required                        pam_unix.so
# end of pam-auth-update config

A questão é a Dec 25 11:45:01 websrv CRON[44085]: pam_unix(cron:session): session opened for user root by (uid=0) texto, que aparentemente de alguma forma foi inserido no pam arquivo de configuração.

Minha suposição aqui e eu estou realmente realmente adivinhando, é que um script estava modificando esse arquivo de um tty anexado ao log de autenticação do kernel de alguma forma, e acidentalmente cated ou echoed o texto no arquivo. Eu nunca toquei em nada pam relacionados.

De qualquer forma, era simples corrigir uma vez que eu encontrei o problema, mas a saída de depuração foi certamente bastante incerta.


0
2018-01-28 07:14