19

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
3
  • You've a user account pknopf in your /etc/passwd, etc., and it can log in? Commented Feb 6, 2018 at 23:45
  • My account is in /etc/passwd. Commented Feb 7, 2018 at 0:26
  • I can "pamtester auth pknopf authenticate" with (running as) root user, but not with pknopf user. Commented Feb 7, 2018 at 7:07

3 Answers 3

24

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
3
  • 1
    This as my issue. It was a result of Docker stripping that privilege bit. github.com/moby/moby/issues/36239 Commented Jun 12, 2018 at 16:08
  • The issue in this question appeared for me at 2025-06-19 after an Ubuntu atuomatic update. This solution fixed my issue. Did Ubuntu change their release without testing for this authentication method? Commented Jun 27 at 13:49
  • Yeah, the last thing was the issue. ownership had reset during a restore from backup. Commented Oct 14 at 11:15
3

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

5
  • 5
    This would create a huge security concern. Commented Jul 6, 2020 at 5:06
  • Please elaborate, and provide an alternative @KongChunHo Commented Jul 9, 2020 at 17:05
  • 4
    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. Commented Jul 9, 2020 at 22:10
  • So really this is the right solution. Commented Jul 10, 2020 at 17:56
  • 4
    This maybe the right solution, but definitely not a safe solution in security standpoint. Commented Jul 10, 2020 at 20:05
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;
1
  • If you had to do that many fixes I'd suggest that maybe you or someone else with root permissions inadvertently removed the suid bit while performing a system-wide chmod Commented Jun 27 at 14:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.