Control: tags -1 + moreinfo
On Thu, 12 Jun 2025 at 15:40:04 +0100, Simon McVittie wrote:
the default configuration of gdm is such
that, if a user has a smart card (e.g. Yubikey) plugged in, but *has
not* enrolled it for smartcard authentication, then gdm doesn't work
as intended for ordinary username/password authentication. This seems
bad.
I tried to reproduce similar problems in a default installation, with a Nitrokey Pro: I don't have a Yubikey, but I assume they're similar
enough to make little difference.
Test scenarios
==============
Scenario 1: default GNOME
-------------------------
* boot from Debian trixie rc2 netinst
* fresh installation onto a laptop
* enable the GNOME and sshd tasks during installation
* plug in my Nitrokey Pro
(which contains GPG signing/auth/encryption keys, if it matters)
* reboot
* expected result: list of users, click to select
Works for me (behaviour is the same as without the Nitrokey plugged in).
Scenario 2: pcscd only
----------------------
Same as scenario 1, but install pcscd (with Recommends) before rebooting.
Works for me (behaviour is the same as without the Nitrokey plugged in).
Scenario 3: install opensc
--------------------------
If I install opensc in addition to pcscd, then I can reproduce what I
think is the symptom that was described by "C" <
[email protected]>:
* Debian trixie rc2 netinst
* a typical installation with GNOME (and sshd)
* sudo apt install opensc (Recommends are enabled)
* plug in Nitrokey Pro
* reboot
* activity LED lights up on my Nitrokey
* user list is replaced by a username input box, enter username
* password box has a message below it:
"SSSD PAM module is not installed, Smart card
authentication is not supported, falling back to default
mechanism"
* I can still log in successfully by entering the test user's password
This is not necessarily ideal - it's a little bit more difficult to log
in if I happen to have my smart card plugged in - but it works.
Scenario 4: install opensc and libpam-sss -----------------------------------------
* Debian trixie rc2 netinst
* a typical installation with GNOME (and sshd)
* sudo apt install opensc libpam-sss (Recommends are enabled)
* plug in Nitrokey Pro
* reboot
* activity LED lights up on my Nitrokey
* user list is replaced by a username input box, enter username
* password box is populated with a message
"Please (re)insert (different) Smar..."
* Below the password box I see a message
"Please (re)insert (different) Smartcard"
* Typing the test user's password into the password box **DOES NOT**
log in successfully
This is the only test scenario I've tried that is actually a
showstopper.
Your scenario here
------------------
If you have identified a different failing scenario that does not match
any of the ones I described above, please describe it with a similar
level of detail. If you have access to a spare laptop, it would be very
helpful if you can reproduce it by starting from a fresh trixie install
(use tasksel tasks and add the necessary packages to reproduce the
problem).
Workarounds and possible solutions
==================================
enable-smartcard-authentication=false
-------------------------------------
Edit /etc/gdm3/greeter.dconf-defaults, locate the header "[org/gnome/login-screen]" and fill in
"enable-smartcard-authentication=false" below it, so it looks something
like this:
...
[org/gnome/login-screen]
enable-smartcard-authentication=false logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
Users can do this edit as a workaround.
This is the brute-force approach that makes sure password authentication definitely always works as expected, at the cost of completely disabling smartcard support.
I have confirmed that this fixes my Scenario 4 (I can log in), and
improves convenience in Scenario 3 (I get a list of users to click on,
and I don't have to type my username).
The GNOME team could change gdm3 to make this the default configuration.
If we do, the cost is that sysadmins who want to enrol smart cards to be
used for authentication will need to revert that change locally at the
same time.
If we decide not to do this, then I think we should add enable-smartcard-authentication=false to the default /etc/gdm3/greeter.dconf-defaults, commented out, so that it's easily
available at a glance for sysadmins.
Use gdm-smartcard-sssd-or-password by default ---------------------------------------------
/etc/pam.d/gdm-smartcard is a symlink to
/etc/alternatives/gdm-smartcard, which currently points to /etc/pam.d/gdm-smartcard-sssd-exclusive by default.
As a workaround, users can run:
sudo update-alternatives --config gdm-smartcard
and choose the /etc/pam.d/gdm-smartcard-sssd-or-password option.
I have verified that this is enough to be able to log in in Scenario 4,
making it behave more like Scenario 3.
The GNOME team could change gdm3 to swap the alternatives priority of /etc/pam.d/gdm-smartcard-sssd-exclusive (currently 50) and /etc/pam.d/gdm-smartcard-sssd-or-password (currently 40) so that the
latter becomes the new default. If we do, the cost is that sysadmins who
want to forbid password authentication will have to adjust the
alternatives to use /etc/pam.d/gdm-smartcard-sssd-exclusive (or /etc/pam.d/gdm-smartcard-pkcs11-exclusive) instead.
If I understand correctly, this is the option that Marco would prefer?
A disadvantage of this approach is that it makes Scenario 4 behave like Scenario 3: if a smart card is plugged in, you don't get a list of users
to click on, and instead you have to type your username.
Both of the above
-----------------
The GNOME team could consider disabling smart card auth by default,
*and* making sssd-or-password the default implementation of smart card
auth if it is enabled.
I don't think this makes sense as a workaround for local sysadmins (one
is enough) but I think it's worth considering as a solution.
Set PCSCLITE_FILTER_IGNORE_READER_NAMES
---------------------------------------
If you only want to use your smart card for GPG and not for other
use-cases such as X.509, you can edit /etc/default/pcscd and add
something like:
PCSCLITE_FILTER_IGNORE_READER_NAMES="Nitrokey"
as per <
https://web.archive.org/web/20231002205728/blog.apdu.fr/posts/2021/08/pcsc-lite-configuration-using/>
and <
https://web.archive.org/web/20230924201853/https://blog.apdu.fr/posts/2015/12/remove-andor-customize-pcsc-reader-names/>.
(Or you could uninstall opensc and pcscd completely.)
This is a workaround that can be used by individual sysadmins, but is
not a solution that can be applied by the GNOME team more generally (we
can't know what you want to use your smartcard for, and it
involves editing other packages' conffiles, which is not allowed).
Something involving gdm-auth-config
-----------------------------------
Marco wrote:
In debian we actually have the `gdm-auth-config` that should allow to
manage this without having to handle this, it also allows to use distro scripts (I did put one in our gdm's debian/* folder) that should handle things, but it may need tunings since my testing was quite in the past compared to when it landed upstream.
But I don't know what this would mean, specifically, so I cannot
implement it. If this is the solution that would be preferred then
someone else will have to implement it.
Older reports
=============
Looking back at older reports:
The original bug report was that Paul Tagliamonte reported that in
45~beta-1, attempting to log in with username and password failed. <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051785#5>
Paul's setup appears to be my Scenario 3 (opensc but no libpam-sss) and
I could not reproduce the reported problem in this scenario. I think
this may have been fixed by "Always fallback to password auth if no SC
pam module is installed" in 45.0.1-1, at which point the bug should
perhaps ideally have been closed.
Raphael Hertzog similarly reported that in 45~beta-1, attempting to log
in with username and password, without installing libpam-sss, failed. <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051785#20>
Again this looks like my Scenario 3 and I think it was fixed in
45.0.1-1.
Raphael also reported in <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051785#20> that by additionally installing libpam-sss, he got a different error message. I
think this is my Scenario 4. Raphael, please could you confirm this
guess, or if my guess is wrong, clarify what your test scenario is and
what its result is? Strictly speaking this should perhaps have been a
different bug report, because it's a different scenario with different expectations.
Harlan Lieberman-Berg said "I've gotten bitten by this one too" but it
is not clear which packages they have installed or which precise symptom
they saw as a result. <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051785#30>
C <
[email protected]> reported what appears to be my Scenario 3,
with what appear to be the same results I observed. <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051785#47>
Luca Boccassi reports that after GNOME 46, "this actually breaks login completely - after typing the password, the greeter is just stuck
there", but it isn't clear to me what combination of packages "this"
refers to. He also confirms that enable-smartcard-authentication=false successfully disables smart card
auth. <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051785#67>
I *think* this is my Scenario 4: Luca, please could you confirm or
clarify?
Thanks,
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)