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


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
  • You've a user account pknopf in your /etc/passwd, etc., and it can log in?
    – roaima
    Feb 6 '18 at 23:45
  • My account is in /etc/passwd.
    – Paul Knopf
    Feb 7 '18 at 0:26
  • I can "pamtester auth pknopf authenticate" with (running as) root user, but not with pknopf user.
    – Paul Knopf
    Feb 7 '18 at 7:07
  • Result of ls -l /sbin/unix_chkpwd added to your question, please.
    – roaima
    Feb 7 '18 at 8:45
  • Updated question to include the output.
    – Paul Knopf
    Feb 7 '18 at 14:46

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

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.


  • 2
    This would create a huge security concern. Jul 6 '20 at 5:06
  • Please elaborate, and provide an alternative @KongChunHo Jul 9 '20 at 17:05
  • 2
    Adding a service user Debian-exim to shadow group allows an attacker read /etc/shadow which contains (hashed) password of the machine when the service is compromised. I do not have an alternative solution, but I just want to point out the security implications. Jul 9 '20 at 22:10
  • So really this is the right solution. Jul 10 '20 at 17:56
  • 2
    This maybe the right solution, but definitely not a safe solution in security standpoint. Jul 10 '20 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.