I’ve been wrestling with PAM and fingerprint authentication on Manjaro, and honestly it has turned into a bit of a nightmare. I’m trying to reproduce a behavior that feels natural on systems like macOS or Android:
At login, or when unlocking, you should be able to choose either your password or your fingerprint.
Both options are valid at the same time – you don’t need to wait for a timeout, or try one first and then the other.
On cold boot / first login, only the password should work (fingerprint disabled until after the first password login). After that, fingerprint can be used for unlocking the session or for sudo prompts.
Currently, with PAM in Manjaro, I can’t get this “parallel” behavior. It feels like PAM forces an order: either it asks fingerprint first and falls back to password on failure, or the other way around. I haven’t found a way to let them coexist like on macOS/Android.
I’m pretty sure this comes down to PAM configuration. Has anyone here managed to set up PAM in such a way that both password and fingerprint are available as valid authentication options without one blocking the other?
Even if you don’t have the exact solution, maybe you could share your PAM configs or setups that are close to what I’m describing. I think seeing how others handle this could give me ideas.
Thanks for your reply. Although, I have followed those instructions before posting and was only able to “partially” achieve what I am looking for.
Right now, I hit enter on an empty password to use fingerprint, but it doesn’t seem like I can enter my password only at cold boot - if I do so, sddm waits for fingerprint to timeout before letting me logging in, which is soooooo annoying.
I’d really like to achieve a pw+biometrics authentication that would not require the knowledge of hitting enter on a blank password - this is gonna be a shared workstation and I want it to be as friendly as possible, like macOS would be.
OK, as you are [quote=“ruelmarc4, post:3, topic:181678”]
able to “partially” achieve what I am looking for.
[/quote]
there is seems that something is missing n the configuration files in /etc/pam.d. You did not mention, what desktop environment you are using, I’m on KDE. Here are my files so you can compare. Be sure to have a backup before any change!
# /etc/pam.d/kde
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_fprintd.so
auth include system-local-login
account include system-local-login
password include system-local-login
session include system-local-login
# /etc/pam.d/login
#%PAM-1.0
auth sufficient pam_fprintd.so
auth required pam_unix.so use_first_pass nullok_secure
#auth include system-login
auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
account include system-local-login
session include system-local-login
password include system-local-login
# /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_fprintd.so
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
password include system-auth
# /etc/pam.d/sudo
#%PAM-1.0
auth sufficient pam_fprintd.so
auth include system-auth
account include system-auth
session include system-auth
# /etc/pam.d/system-local-login
#%PAM-1.0
auth sufficient pam_fprintd.so
auth include system-login
account include system-login
password include system-login
session include system-login
With you config, everything seems to work well, except for the tricky part: apps that leverage Policy Kit like Bitwarden.
For example, if I want to unlock Bitwarden using system authentication (PolKit), I have to use fingerprint only, or type my password and wait until fprintd times out (15 seconds).
Here is my /etc/pam.d/polkit-1 file
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so try_first_pass nullok_secure
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
However, having a polkit-1 overrides all the granular configs we’ve made… May I ask for your advice on this one too?
I’ve ended up using module pam_fprintd_grosshack.so, which lets you use fingerprint or password at the same moment and add it directly to system-auth, instead of tweaking each file. Then, in my SDDM file, I’ve explicitely used module pam_unix.so for auth purposes.
This gives me almost exactly what I was looking for:
Password auth at boot, first login
Fingerprint afterwards for unlocking or GUI auth
Sudo auth using pam_fprintd.so explicitely, so fingerprint or password if cancelled by CTRL+C.
If anyone has another solution that would be “cleaner”, I’d be glad to know about it!
Perhaps you could expand on this for the benefit of others who might find themselves in a similar predicament – a description of steps taken; possibly links to specific information needed.
You are totally right! Note here that I’m not an expert, just a power user trying to make something work with what’s available. So If anyone has another technique or a more efficient way, you are welcome to share with us folks!
My Machine Info
OS: Manjaro KDE with kernel 6.12.44-3
Hardware: Lenovo P14s Gen 1 with Synaptics Prometheus fingerprint sensor
Here’s more detailed information about my now “optimal” configuration. To me, the key points of success were:
KDE login screen (SDDM) would not permit a fingerprint login, just like macOS or Android.
KDE’s lock screen could use either fingerprint or password, evaluated at the same time and not one before the other.
Any other elevation prompt would act the same way.
Configuration Files
From a brand-new Manjaro install—with /etc/pam.d untouched until now, so be sure to take a backup! —I’ve only modified these files:
/etc/pam.d/kde
/etc/pam.d/system-auth
/etc/pam.d/sddm
Here’s the content of each file for everyone’s benefit.
/etc/pam.d/kde
#%PAM-1.0
auth sufficient pam_fprintd_grosshack.so
auth include system-local-login
account include system-local-login
password include system-local-login
session include system-local-login
/etc/pam.d/system-auth
#%PAM-1.0
auth required pam_faillock.so preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth [success=2 default=ignore] pam_systemd_home.so
auth sufficient pam_fprintd_grosshack.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
auth optional pam_permit.so
auth required pam_env.so
auth required pam_faillock.so authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.
-account [success=1 default=ignore] pam_systemd_home.so
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so
-password [success=1 default=ignore] pam_systemd_home.so
password required pam_unix.so try_first_pass nullok shadow
password optional pam_permit.so
-session optional pam_systemd_home.so
session required pam_limits.so
session required pam_unix.so
session optional pam_permit.so
/etc/pam.d/sddm
#%PAM-1.0
# Authenticate with password only
auth required pam_unix.so try_first_pass nullok
# Optional: keyring / KWallet (won't prompt on login)
auth optional pam_gnome_keyring.so
auth optional pam_kwallet5.so
account include system-login
password include system-login
session optional pam_keyinit.so force revoke
session include system-login
session optional pam_gnome_keyring.so auto_start
session optional pam_kwallet5.so auto_start
I haven’t found enough information about the pam_fprintd_grosshack.so module yet, but it works as intended. I’ll continue my research on a new GitHub project called pam-any (pam_any.so) that could be integrated to make PAM evaluate more than one condition at the same time, instead of its sequential behavior.
The marked solution has been moved to your final summary.
The topic will close automatically in just a few days; however, if you feel the need to update this information at any time (even if closed) please send a PM to any of the Moderation staff and ask to re-open it temporarily.