16

Command

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

As it stands right now, every lock screen will prevent me from "unlocking" (KDE lock screen, i3lock, etc).

If I start i3lock as sudo, I can then properly type in the root password to unlock the screen. However, if I run it as normal user, and I can't use normal user or root password to unlock.

Here is my PAM config for 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

Running ls -l /etc/passwd /etc/shadow /etc/group shows

-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

This is a fresh install of Arch, so I don't think the configuration is too wonky. What should I be looking for to debug this?

Running ls -l /sbin/unix_chkpwd shows

-rwxr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd
Paul Knopf
  • 1,151
  • 2
  • 13
  • 25

3 Answers3

21

Your system installation appears to be broken. For some reason, the file /sbin/unix_chkpwd has lost the privilege bits I would expect to see.

Fix the permissions by running the following command as root:

chmod u+s /sbin/unix_chkpwd

And verify the permissions are now as follows (see the s bit in the user permissions):

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

On my Raspbian distribution the permissions are set slightly differently (and more restrictively). If the change described above does not work, carefully change the permissions on these two files and see if this helps (the group name does not matter too much as long as it's the same in both cases):

-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
Kevin
  • 137
  • 1
  • 9
roaima
  • 107,089
  • 14
  • 139
  • 261
  • 1
    This as my issue. It was a result of Docker stripping that privilege bit. https://github.com/moby/moby/issues/36239 – Paul Knopf Jun 12 '18 at 16:08
4

On a Debian machine, in my case I had to add exim4 user to the shadow group. 

usermod -a -G shadow Debian-exim

PAM: On Debian systems the PAM modules run as the same user as the calling program, so they cannot do anything you could not do yourself, and in particular cannot access /etc/shadow unless the user is in group shadow. - If you want to use /etc/shadow for Exim's SMTP AUTH you will need to run exim as group shadow. Only exim4-daemon-heavy is linked against libpam. We suggest using saslauthd instead.

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

Daniel Sokolowski
  • 211
  • 2
  • 6
1

Had the same issue, but additionally had to fix the permission of the

chmod u+s /bin/sudo
chmod u+s /sbin/unix_chkpwd
chmod u+s /usr/bin/su

Error was

unix_chkpwd[37679]: password check failed for user XXX
su: pam_unix(su-l:auth): authentication failure;
Greenonline
  • 1,759
  • 7
  • 16
  • 21
user202677
  • 11
  • 1