PAM: échec d'authentification, avec mot de passe valide

Commander

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

Dans l'état actuel des choses, chaque écran de verrouillage m'empêchera de "déverrouiller" (écran de verrouillage KDE i3lock, etc.).

Si je démarre en i3locktant que sudo, je peux alors saisir correctement le mot de passe root pour déverrouiller l'écran. Cependant, si je l'exécute en tant qu'utilisateur normal et que je ne peux pas utiliser un utilisateur normal ou un mot de passe root pour le déverrouiller.

Voici ma configuration PAM pour 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

Exécution de ls -l /etc/passwd /etc/shadow /etc/groupspectacles

-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

Il s'agit d'une nouvelle installation d'Arch, donc je ne pense pas que la configuration soit trop bancale. Que dois-je rechercher pour déboguer cela?

Exécution de ls -l /sbin/unix_chkpwdspectacles

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

pam

— Paul Knopf
source

Vous avez un compte utilisateur pknopfdans votre /etc/passwd, etc., et il peut se connecter?

— roaima

Mon compte se trouve dans / etc / passwd.

— Paul Knopf

Je peux "pamtester auth pknopf authenticate" avec (en tant qu'utilisateur root), mais pas avec l'utilisateur pknopf.

— Paul Knopf

Résultat ls -l /sbin/unix_chkpwdajouté à votre question, s'il vous plaît.

— roaima

Question mise à jour pour inclure la sortie.

— Paul Knopf

Réponses:

L'installation de votre système semble être interrompue. Pour une raison quelconque, le fichier /sbin/unix_chkpwda perdu les bits de privilège que je m'attendais à voir.

Corrigez les autorisations en exécutant la commande suivante en tant que root:

chmod u+s /sbin/unix_chkpwd

Et vérifiez que les autorisations sont maintenant les suivantes (voir le sbit dans les autorisations utilisateur):

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

Sur ma distribution Raspbian, les autorisations sont définies légèrement différemment (et de manière plus restrictive). Si la modification décrite ci-dessus ne fonctionne pas, modifiez soigneusement les autorisations sur ces deux fichiers et voyez si cela aide (le nom du groupe n'a pas trop d'importance tant qu'il est le même dans les deux cas):

-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
source

C'est mon problème. C'était le résultat de la suppression de ce bit de privilège par Docker. github.com/moby/moby/issues/36239

— Paul Knopf

Sur une machine Debian, dans mon cas, j'ai dû ajouter un utilisateur exim4 au shadowgroupe.

usermod -a -G shadow Debian-exim

PAM: Sur les systèmes Debian, les modules PAM fonctionnent comme le même utilisateur que le programme appelant, ils ne peuvent donc rien faire que vous ne puissiez pas faire vous-même, et en particulier ne peuvent accéder à / etc / shadow que si l'utilisateur est dans l'ombre de groupe. - Si vous souhaitez utiliser / etc / shadow pour l'AUTH SMTP d'Exim, vous devrez exécuter exim en tant qu'ombre de groupe. Seul exim4-daemon-heavy est lié à libpam. Nous suggérons d'utiliser saslauthd à la place.

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

— Daniel Sokolowski
source