Nitrokey and pam_sss?

In recent versions of Ubuntu and Ubuntu-based OS’s, there is this annoying bug with Gnome Display Manager where if you have a smartcard inserted it won’t let you log in via anything but pam_sss until you pull the card out (see Bug #1933027 “Gdm3 with smartcard asks for login/smartcard pin e...” : Bugs : gdm3 package : Ubuntu). I’ve tried to update-alternatives to allow for sssd or password login, but as others appear to be experiencing that isn’t working (see authentication - Disable Smartcard Integration in Hirsute? - Ask Ubuntu).

I’m quite attracted to the notion of smartcard login, but have found the pam_p11/poldi way suggested in the Nitrokey documentation to be too unstable. When we were using it in the office it had loads of times where the key wasn’t properly registering and causing staff to lock their keys.

I have access to Nitrokey Pro2, Nitrokey Key FIDO U2F, Nitrokey FIDO2, and Nitrokey Storage. Do any of these support pam_sss?

Given that Nitrokey ships Nitropads running these later versions of Ubuntu I’m hoping you guys have been able to work this out, by either allowing pam_sss login or finding a workable workaround. Any advice would be much appreciated.

Hey hey,

so far I understand, in sssd security keys should be in general working (using certificates and nssdb) as long as they support pkcs#11, but I am not aware how a direct support for pam_sss should look like and further not even sure if this is the intended use for sss as it seems to be more of a middleware approach, while nssdb being more of the certificate/secret provider in this context. Feel free to correct me, no real experience using sss here…

Moreover it might be easier to achieve this using pam_pkcs11


I think that is indeed the approach taken in the Nitrokey manual, no? I haven’t found it to be the most stable. And from what I’ve read it seems like having any other type of login is a bit dangerous with this gdm bug hanging around.

Agree, it’s all a bit confusing with the smartcard login being effectively enabled by default and seemingly impossible to turn off. It presupposed not only enterprise login, but enterprise login using smartcards, which, while very much in use across a wide range of sectors, is still not exactly universal.

I wonder how things have been working with Nitropads?

I think it uses pam_poldi but admittedly I’ve not tried this out by myself, from some searching I think it is still a good option and here: pam_tally2 in Kombination mit Nitrokey: Linux Nutzer-Authentifikation ⋆ Kuketz IT-Security Blog are some details how to avoid blocking the account for non-smartcard logins…

Nevertheless the manual you are referring to is going to be deprecated soon, we have now, but this particular thing is not included yet, but will be…

Nitropads use the Nitrokeys to verify the firmware to avoid evil-maid attacks and such, but are not using a Nitrokey based login out-of-the-box

Nitropads use the Nitrokeys to verify the firmware to avoid evil-maid attacks and such, but are not using a Nitrokey based login out-of-the-box

Right. But Nitrokeys can be used for so much more post-boot, so I figured the idea was really to keep the Nitrokey plugged in while the computer was in use, and as such figured that Nitropad users will have raised this problem up the chain at some point. No worries if not, of course, but it’s definitely a problem I’d expect to be hearing about!