Yrurtj

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

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 with the following command, run as root:

chmod u+s /sbin/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.

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