PAM + Fingerprint Authentication – How to Allow Password or Fingerprint (Like macOS/Android)?

Hi everyone,

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 a lot for any suggestions!

A warm welcome to @ruelmarc4, enjoy your MANJARO experiences!
I solved the fingerprint authentication following this description.

2 Likes

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.

Any idea to go further in that way?

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
1 Like

I’ll try to figure out if your config could be the one I am looking for. I am on KDE also, just like you so this should help.

Will let you know afterwards!

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!

1 Like

@ruelmarc4

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.

I’m sure it will be appreciated.

Regards.

1 Like

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!


:computer: 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 :gear:. To me, the key points of success were:

  1. KDE login screen (SDDM) would not permit a fingerprint login, just like macOS or Android.
  2. KDE’s lock screen could use either fingerprint or password, evaluated at the same time and not one before the other.
  3. Any other elevation prompt would act the same way.

:clipboard: Configuration Files

From a brand-new Manjaro install—with /etc/pam.d untouched until now, so be sure to take a backup! :wink:—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.


:link: Pertinent Info

3 Likes

Well done.

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.

Regards.

2 Likes

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.