PAM configuration - Does it make sense to add pam_deny after pam_u2f?

I’m wondering if you should deny password fallbacks if pam_u2f module doesn’t succeed, e.g.:

auth       sufficient                   authfile=/etc/Nitrokey/u2f_keys cue prompt
auth       requisite         

Docs only seem to mention u2f in the role of a second factor or leaving passwords as a fallback. Is using pam_deny excessive? Am I missing a bigger picture here - some scenarios in which this could backfire?

EDIT: It seems like this should be provided with requisite option without needing pam_deny, but for some reason it doesn’t work - it still keeps asking for password after successful pam_u2f.

I’m a PAM amateur, but my issues have been with apps (specifically, GUI apps) expecting some sort keyboard input. SDDM, for example, sits and stares stupidly at you waiting for some sort of text input, so I can’t use pam_u2f to log in. However, systems like SDDM also have their own PAM configuration files, so you might to work around non-pam_u2f-supporting systems by overriding the “default” settings.

My suggestion is to work for a bit with a password fallback, assuming that PAM will fall back if it can’t detect your Nitrokey. I’ve had PAM soft-lock waiting for a definite fail signal before moving onto the next authentication system. If you can go for a while without issues, then try going fully passwordless. Just keep a recovery boot disc handy in case you get locked out of your system on the next dist-upgrade.

In summary, Nitrokey on pam_u2f works fine (from my experience). However, some apps (cough, KDE) don’t know how to deal with non-password authentication methods.

1 Like

thanks for the heads up, I haven’t tested SDDM yet, but I will make sure to have its archwiki article at hand if it denies access on the next login. Overall it seems to be working fine so far, but I wasn’t sure if it’s okay to put the two lines above at the top of the main pam.d configuration file and ignore all the other modules (e.g.,, and - are they irrelevant when you are not using passwords).

Unfortunately, there are known deficits in SDDM where ArchWiki won’t be of much help.

In terms of what’s “safe” or “recommended,” your best bet is to mess around and find out (and try to document your findings to spare others the learning curve).

Strictly speaking, as you probably know, PAM works like a firewall that slides down a rules list until it finds the first matching rule. In theory, any client software should be indifferent to how PAM authenticates and only care if PAM authenticates.

In practice, though, the client relays information to PAM, so it must assume that PAM is configured in a certain way to accept what the client’s sends it. That’s given me unexpected or irritating results.

1 Like

True, I was a bit disappointed that PAM, such a safety-critical system had so few examples how to set it up for common use cases (e.g. passwordless). Second factor is very well documented I think by Nitrokey, yubikey and some other smart card providers, but the “trick” with shown above wasn’t. Or maybe I haven’t given the manual enough attention…

Sorry, still haven’t rebooted to test SDDM, but thanks for the link - I haven’t changed neither pam.d/sddm nor pam.d/kde, so I assume that it will still just use passwords.

I also wonder if it will work any differently on hyprland/wayland…