PAM: falha na autenticação, com senha válida

Comando

pamtester -v auth pknopf authenticate
pamtester: invoking pam_start(auth, pknopf, ...)
pamtester: performing operation - authenticate
Password:
pamtester: Authentication failure

journctl

Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: check pass; user unknown
Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: password check failed for user (pknopf)
Feb 06 13:22:17 PAULS-ARCH pamtester[31997]: pam_unix(auth:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  user=pknopf

Como está agora, todas as telas de bloqueio me impedirão de "desbloquear" (tela de bloqueio do KDE i3lock, etc).

Se eu começar i3lockcomo sudo, posso digitar corretamente a senha root para desbloquear a tela. No entanto, se eu o executar como usuário normal e não puder usar a senha de usuário ou raiz normal para desbloquear.

Aqui está minha configuração do PAM para i3lock.

#
# PAM configuration file for the i3lock screen locker. By default, it includes
# the 'system-auth' configuration file (see /etc/pam.d/login)
#
auth include system-auth

ls -l /etc/passwd /etc/shadow /etc/groupShows em execução

-rw-r--r-- 1 root root 803 Feb 6 14:16 /etc/group
-rw-r--r-- 1 root root 1005 Feb 6 14:16 /etc/passwd
-rw------- 1 root root 713 Feb 6 14:16 /etc/shadow

Esta é uma nova instalação do Arch, então não acho que a configuração seja muito complicada. O que devo procurar para depurar isso?

ls -l /sbin/unix_chkpwdShows em execução

-rwxr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd

pam

— Paul Knopf
fonte

Você tem uma conta de usuário pknopfna sua /etc/passwdetc., e ela pode fazer login?

— roaima

Minha conta está em / etc / passwd.

— Paul Knopf

Eu posso "pamtester auth pknopf authenticate" com (executando como) usuário root, mas não com pknopf user.

— Paul Knopf

Resultado de ls -l /sbin/unix_chkpwdadicionado à sua pergunta, por favor.

— roaima

Pergunta atualizada para incluir a saída.

— Paul Knopf

Respostas:

A instalação do seu sistema parece estar com problemas. Por alguma razão, o arquivo /sbin/unix_chkpwdperdeu os bits de privilégio que eu esperaria ver.

Corrija as permissões executando o seguinte comando como root:

chmod u+s /sbin/unix_chkpwd

E verifique se as permissões agora são as seguintes (veja o sbit nas permissões do usuário):

-rwsr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd

Na minha distribuição Raspbian, as permissões são definidas de maneira um pouco diferente (e mais restritiva). Se a alteração descrita acima não funcionar, altere cuidadosamente as permissões nesses dois arquivos e veja se isso ajuda (o nome do grupo não importa muito, desde que seja o mesmo nos dois casos):

-rw-r----- 1 root shadow  1354 Dec  6 13:02 /etc/shadow
-rwxr-sr-x 1 root shadow 30424 Mar 27  2017 /sbin/unix_chkpwd

— roaima
fonte

Este é o meu problema. Foi o resultado de o Docker remover esse bit de privilégio. github.com/moby/moby/issues/36239

— Paul Knopf,

Em uma máquina Debian, no meu caso, tive que adicionar o exim4 user ao shadowgrupo.

usermod -a -G shadow Debian-exim

PAM: Nos sistemas Debian, os módulos PAM são executados como o mesmo usuário do programa de chamada, portanto, eles não podem fazer nada que você não possa fazer, e em particular não podem acessar / etc / shadow, a menos que o usuário esteja na sombra do grupo. - Se você quiser usar o / etc / shadow para o SMTP AUTH do Exim, precisará executar o exim como sombra de grupo. Somente o exim4-daemon-heavy está vinculado ao libpam. Sugerimos o uso de saslauthd.

http://lira.no-ip.org:8080/doc/exim4-base/README.Debian.html

— Daniel Sokolowski
fonte