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.
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. pam_faillock.so, pam_systemd_home.so, pam_unix.so and pam_env.so - are they irrelevant when you are not using passwords).
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.
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 pam_deny.so 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…
