Hey GNOME maintainers, I upgraded my sid system, and post-upgrade gdm3 isn't showing my face when I reboot, and entering my username causes it to loop back to username entry again (no password prompt). After some help from smcv, I narrowed down the issue to the interactions between my smartcard development tools installed locally and gdm3. The journal shows the following output: | Sep 12 10:18:47 nyx gdm-launch-environment][1851]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm(uid=116) by (uid=0) | Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory | Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM adding faulty module: pam_sss.so | Sep 12 10:19:02 nyx gdm-smartcard][2749]: gkr-pam: no password is available for user | Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory | Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM adding faulty module: pam_sss.so | Sep 12 10:19:03 nyx gdm-smartcard][3505]: gkr-pam: no password is available for user | Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory | Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM adding faulty module: pam_sss.so | Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory | Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM adding faulty module: pam_sss.so | Sep 12 10:19:34 nyx gdm-smartcard][4045]: gkr-pam: no password is available for user | Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM unable to dlopen(pam_sss.so): /lib/security/pam_sss.so: cannot open shared object file: No such file or directory | Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM adding faulty module: pam_sss.so (I do not have libpam-sss installed - after I got this error I installed it to see if I could unlock myself, but it didn't do much and I purged it again). I have not configured my machine to use gdm-smartcard (nor do I want to); but I do have a lot of smartcard stuff installed due to other hobby work. I have NSS set up to talk with OpenSC, but that's only for TLS keying material via GNOME, not system login. When I unplugged my Yubikey which is both WebAuthN and a x.509 Smartcard, I was able to log in as usual. My hunch is that I believe gdm-smartcard thinks it's supposed to kick into gear and authenticate my smartcard, but it isn't configured to do so (heck, it hasn't been told how to match my UPN/Email SAN/Subject/Serial to UID, nor an x.509 CA to use for user authentication). However, it kicking into gear has kicked me out of my ability to login :) I suspect the fix here is to explicitly toggle on gdm-smartcard when it's properly configured, rather than implicitly running when the right deps are installed and an x509 cert is found on an OpenSC token when it can't properly authenticate it. Fondly, paultag
"NSS" is unfortunately ambiguous in this context. Is this the glibc Name
Service Switch (the thing that for example libnss-systemd integrates
with), or Mozilla's Netscape Security Services (libnss3), or some secret
third thing also named NSS?
Whichever one it is, can you be more specific about what was involved in
"setting it up to talk with OpenSC"?
smcv
Ah, very sorry. libnss3. I usually use OpenSC in the following configuration: ``` modutil -add "OpenSC" \ -libfile /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so \ -dbdir sql:$HOME/.pki/nssdb ``` However, when I went to confirm my notes[1] against my running system, I found it to be in a different state (using onepin-opensc-pkcs11.so, which is new to me): | An aside: | | [1]: My notes are in the form of manpages for stuf I do infrequently but | want to remember. Here's a markdon of the yubkey manpage when I noodle | with using it in OpenSC mode, in case this is helpful for more | information: https://gist.github.com/paultag/2c35b62e85a032856c2cb97345c3d24d | | That's from 2017, so the world has changed quite a bit, and some of it | is bad / outdated advice, so I'd just use it to help understand likely | system configuration than best practice -- for instance, don't use | pkcs#11 for ssh keys anymore pls :) Related output when using `modutil -list -dbdir sql:$HOME/.pki/nssdb` I'm seeing a slightly different configuration (hurmm, odd): ``` 2. OpenSC smartcard framework (0.22) library name: /usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so uri: pkcs11:library-manufacturer=OpenSC%20Project;library-description=OpenSC%20smartcard%20framework;library-version=0.23 slots: 1 slot attached status: loaded slot: token: uri: pkcs11: ``` dpkg output from the packages I know about off the top of my head that would be involved that aren't in the last report: ii opensc 0.23.0-1 amd64 Smart card utilities with support for PKCS#15 compatible cards ii opensc-pkcs11:amd64 0.23.0-1 amd64 Smart card utilities (PKCS#11 module) ii libnss3:amd64 2:3.92-1 amd64 Network Security Service libraries ii libnss3-dev:amd64 2:3.92-1 amd64 Development files for the Network Security Service libraries ii libnss3-tools 2:3.92-1 amd64 Network Security Service tools ii libykpiv-dev:amd64 2.2.0-1.1 amd64 Development files for the YubiKey PIV Library ii libykpiv2:amd64 2.2.0-1.1 amd64 Library for communication with the YubiKey PIV smartcard ii pcscd 2.0.0-1 amd64 Middleware to access a smart card using PC/SC (daemon side) ii libccid 1.5.2-1 amd64 PC/SC driver for USB CCID smart card readers
Hello,
on purpose), I just have a smartcard inserted with a single GPG key used
for "authentication" (i.e. mainly for SSH logins).
$ gpg --card-status
Reader ...........: Alcor Micro AU9540 00 00
Application ID ...: D2760001240102010005000040DD0000
Application type .: OpenPGP
Version ..........: 2.1
Manufacturer .....: ZeitControl
[...]
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: 1CAC 8718 CAA0 C7B9 1EC0 E907 F1CA EE10 6CE6 97F8
created ....: 2022-01-19 08:31:51
At least after I installed libpam-sss, I got an error message asking me
to introduce another smartcard so we could indeed figure out that it was
related to the smartcard.
That's likely due to the fact that gdm-smartcard required dependencies
(at least libpam-sss) were missing. So yeah it seems like that
gdm-smartcard should have a better failure mode when its prerequisites are
missing.
Putting here the reportbug generated info for the computer where I
experienced the issue:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gdm3 depends on:
ii accountsservice 23.13.9-4
ii adduser 3.137
ii dbus [default-dbus-system-bus] 1.14.10-1
ii dbus-bin 1.14.10-1
ii dbus-daemon 1.14.10-1
ii dconf-cli 0.40.0-4
ii dconf-gsettings-backend 0.40.0-4
ii debconf [debconf-2.0] 1.5.82
ii gir1.2-gdm-1.0 45~beta-1
ii gnome-session [x-session-manager] 44.0-4
ii gnome-session-bin 44.0-4
ii gnome-session-common 44.0-4
ii gnome-settings-daemon 45~rc-1
ii gnome-shell 44.4-1
ii gnome-terminal [x-terminal-emulator] 3.49.99-1
ii gsettings-desktop-schemas 45~rc-1
ii libaccountsservice0 23.13.9-4
ii libaudit1 1:3.1.1-1
ii libc6 2.37-7
ii libcanberra-gtk3-0 0.30-10
ii libcanberra0 0.30-10
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libgdm1 45~beta-1
ii libglib2.0-0 2.78.0-1
ii libglib2.0-bin 2.78.0-1
ii libgtk-3-0 3.24.38-5
ii libgudev-1.0-0 237-2
ii libkeyutils1 1.6.3-2
ii libpam-modules 1.5.2-7
ii libpam-runtime 1.5.2-7
ii libpam-systemd [logind] 254.1-3
ii libpam0g 1.5.2-7
ii librsvg2-common 2.54.7+dfsg-2
ii libselinux1 3.5-1
ii libsystemd0 254.1-3
ii libx11-6 2:1.8.6-1
ii libxau6 1:1.0.9-1
ii libxcb1 1.15-1
ii libxdmcp6 1:1.1.2-3
ii metacity [x-window-manager] 1:3.49.1-1
ii mutter [x-window-manager] 44.4-2
ii polkitd 123-1
ii procps 2:4.0.3-1
ii systemd-sysv 254.1-3
ii ucf 3.0043+nmu1
ii x11-common 1:7.7+23
ii x11-xserver-utils 7.7+9+b1
ii xterm [x-terminal-emulator] 384-1
Versions of packages gdm3 recommends:
ii at-spi2-core 2.49.91-2
ii desktop-base 12.0.6+nmu1
ii gnome-session [x-session-manager] 44.0-4
ii x11-xkb-utils 7.7+7
ii xserver-xephyr 2:21.1.8-1
ii xserver-xorg 1:7.7+23
ii zenity 3.44.2-1
Versions of packages gdm3 suggests:
pn libpam-fprintd <none>
ii libpam-gnome-keyring 42.1-1+b2
pn libpam-pkcs11 <none>
pn libpam-sss <none>
ii orca 44.1-2
Cheers,
Ahha! As do I! I removed all my tokens, and understood smartcard to mean
an x.509 credential. My Debian signing key is on Hardware as well.
Application ID ...: D2760001240102010006075352630000
Application type .: OpenPGP
Version ..........: 2.1
Manufacturer .....: Yubico
[...]
Name of cardholder: [not set]
Language prefs ...: [not set]
Salutation .......:
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa4096 rsa4096 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : [...]
Signature counter : [...]
Signature key ....: B7EC F42D DFD9 8AC7 301C 062B 1101 AD5A 8136 9AD7
created ....: 2019-02-09 15:52:11
paultag
I've gotten bitten by this one too, I'm afraid, this time in Debian testing. Potentially interestingly, though I do have a PKCS#11 token inserted, it has no certificates on it. That's still enough to trigger the bug, however, even though there is no certificate for it to even attempt to auth against. For example: ``` ❯ pkcs11-tool -L Available slots: Slot 0 (0x0): Yubico YubiKey OTP+FIDO+CCID 00 00 token label : PIV_II token manufacturer : piv_II token model : PKCS#15 emulated token flags : login required, rng, token initialized, PIN initialized, user PIN locked hardware version : 0.0 firmware version : 0.0 serial num : 00000000 pin min/max : 4/8 ``` However... ``` ❯ pkcs11-tool --list-objects --type cert Using slot 0 with a present token (0x0) ``` Sincerely,
If you run as root
update-alternatives --set gdm-smartcard /etc/pam.d/gdm-smartcard-sssd-or-password
does that restore previous functionality?
If I understand the situation correctly, when gdm detects the presence of
a smartcard, it switches from its default gdm-password PAM profile to
gdm-smartcard, which is an alias for either gdm-smartcard-pkcs11-exclusive,
gdm-smartcard-sssd-exclusive or gdm-smartcard-sssd-or-password.
However, in the two -exclusive profiles, "exclusive" means "password
login is not allowed, only smartcard login can work" - which obviously
isn't right if you don't have smartcard-related PAM modules installed,
or if you haven't configured any {smartcard -> user account} mappings.
If my understanding is correct, then I think
gdm-smartcard-sssd-or-password would be a better default, unless
there are factors here that I'm not seeing. Sysadmins could still set
the alternative to point to gdm-smartcard-sssd-exclusive for a more
locked-down system, but only after ensuring that smartcard-based login
has been configured and actually works!
(Explicitly cc'ing Marco here since he seems to be the expert on gdm's
interactions with PAM, and the one driving the smartcard handling
enhancements that seem to have triggered this regression.)
smcv
longer a list of users to select from; it is a username box where the "go back" button does nothing), but you can login by putting the username in by hand. That part is, obviously, the most important one. Is the issue here one of defaults (e.g., the wrong PAM profile being set), or one of detection (are smartcards a valid choice at all)? Potentially unrelated sidenote: setting `/org/gnome/login-screen/enable-smartcard-authentication` to `false` has no effect on the ability to login; it still refuses to allow password auth. Sincerely,
I found myself here with the same issue (although it took a while to find this bug): I have a YubiKey and suddenly at login my user would appear for a split second and then be replaced by the blank username field. After entering the username gdm3 would show "SSSD PAM module is not installed. Smart card authentication is not supported, falling back to default mechanism" This started for me a few weeks ago, right around the time I installed opensc for some smart card work I needed to do. I managed to "fix" the behaviour (it's more of a workaround IMO) by running this command sudo -u Debian-gdm env -u XDG_RUNTIME_DIR -u DISPLAY DCONF_PROFILE=gdm dbus-run-session gsettings set org.gnome.login-screen enable-smartcard-authentication false that Marco suggested on https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1933027/comments/17 (all I had to do was change the sudo username from gdm to Debian-gdm). Neither the dconf workaround suggested above, nor setting the gsettings entry on my user or as root, worked and I suspect it's because the value on the Debian-gdm user takes precedence. For the record I didn't try the other suggestion in the bug (creating /etc/pam.d/gdm-password and using update-alternatives to set that as the default for gdm-smartcard), but maybe Debian should have this as an option for people that run into this issue? If that's a valid option then believe it would be a simple addition to have that file (even called something else, like "gdm-no-smartcard", "gdm-password-only", etc.) in place, even if it's not the default. Also of note, my installed alternative was "gdm-smartcard-sssd-exclusive" and it was still falling back to password. Hope this helps!
affect the behaviour of the gdm greeter, because the gdm greeter does not run as your user, or as root: it runs as Debian-gdm (or as gdm on Ubuntu). So that part is as working as designed: if you want to change the behaviour of the greeter, it is the Debian-gdm user's settings that must be changed, and no other user's personal settings are going to affect it. What dconf workaround would that be? I don't see one in the previous messages to this bug. The intended way to change the settings of the Debian-gdm user is to edit /etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent would be to locate the line "[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' ... And then restart gdm (the easiest/most reliable way is to reboot). However, if you have already used a workaround that edits the user's settings, like this one: then that is probably going to take a higher priority than whatever you write into /etc/gdm3/greeter.dconf-defaults. Debian, so I'm not going to make changes to it without understanding his design intentions. I personally think using smart cards as orthogonal to PAM authentication is likely to be more common than using them for PAM authentication, and if I understand correctly, using smart cards for authentication needs sysadmin configuration *anyway* to associate each smartcard with a user ID; so I would personally prefer it if the default was to use ordinary password authentication, with some sort of opt-in for using smart cards to authenticate, which sysadmins would be expected to enable after they have enrolled users (set up the smartcard -> user mapping). In RHEL, it seems to be opt-in: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/authenticating-the-user-in-the-desktop-environment_using-the-desktop-environment-in-rhel-8#configuring-smartcard-authentication-in-gdm-using-the-command-line_authenticating-the-user-in-the-desktop-environment Doing the equivalent in Debian/Ubuntu might make more sense than trying to guess whether smart card authentication is wanted from whether smart card hardware happens to be plugged in? Or, perhaps smart card authentication could be active if and only if at least one smartcard -> user mapping has been created? Or, perhaps enable-smartcard-authentication should be one of the fields that is included in our example /etc/gdm3/greeter.dconf-defaults ready for users to edit? The default could be either true or false, whichever seems more appropriate. smcv
messages to this bug. Very sorry, I got confused: I read somewhere that creating a file in /etc/dconf/[subdirectory I can't remember] would've solved this. I can't find the place I read that anymore, and for some reason I believed it was in this bug; however, I think it was exactly what the RedHat guide you linked describes. edit /etc/gdm3/greeter.dconf-defaults [...] Understood, thank you; I'll keep this in mind. Agreed; I also think there's more users tinkering with smart cards (or installing smart card tooling as a dependency to some other software) than there are users using them for authentication. I don't know exactly what triggered this behaviour in GDM; I tried to reproduce on a VM by installing opensc (which pulled in pcscd too) and upgrading first to trixie and then sid, but nothing triggered it. It may be another package, happy to test if you have suggestions. IMO this seems appropriate, and matches your intention of not touching Marco's design; I would default to false and document this as a requirement for using smart card authentication, but it may be considered a breaking change (the current default is true, I believe) so I'm not sure how you want to handle it.
Red Hat's setup for how gdm is configured is not quite the same as
Debian's, so Red Hat guides don't necessarily apply 100% to Debian.
smcv
edit would I can confirm this works (I too have a yubikey with a cert for unrelated purposes). Previously this was a mere annoyance as it just meant having to type the username manually, which is no big deal. However, since gnome 46 migrated to testing, this actually breaks login completely - after typing the password, the greeter is just stuck there.
Control: retitle -1 gdm3 won't allow logins when a smartcard/yubikey is plugged Control: severity -1 serious So we should deploy this by default IMO. I have setup a new computer today and I have again been bitten by this issue. Increasing severity to attract more eyes and maybe trigger an upload. And fixing the subject to actually match a search on "smartcard". Cheers,
in this, rather than second-guessing his design.
Marco: can we set
[org/gnome/login-screen]
enable-smartcard-authentication=false
by default in /etc/gdm3/greeter.dconf-defaults? That would be one more
thing that sysadmins have to adjust when they enrol smart cards for
authentication, but it seems preferable to having Yubikey/Nitrokey users
unable to log in by default.
Or do you have some other plan for this?
I'm setting a deadline for this: if I don't see objections within the
next week, I intend to upload that change to unstable.
smcv
Hi, 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. So... I feel that such tool should be instead used to setup things, while it can be used by sysadmins quickly, in theory, to enable it back
Are you aware of the issue reported as #1051785?
The short version is that 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.
It's great that there are tools available to partially or fully automate
smartcard authentication setup, but if the sysadmin has not done any
setup or enrolled any smart cards, the default needs to be something
where ordinary username/password authentication still works. I don't
want to undo your hard work on this, but we do need the common case to
be reliable.
smcv
I think a similar thing was reported in ubuntu too, but I had not enough time to fully handle it, however IIRC another option may be to use use update-alternatives --config gdm-smartcard pointing to /etc/pam.d/gdm-smartcard-sssd-or-password instead? That would control the PAM service that is used by gdm by default, we could also add a NULL value to it to disable it completely instead
Control: tags -1 + moreinfo
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" <flyingstar16@gmail.com>:
* 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:
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 <flyingstar16@gmail.com> 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
...
...
Both of these are implemented in
<https://salsa.debian.org/gnome-team/gdm/-/merge_requests/30>. We should
either choose one of them and revert the other, or do both, or do some
fourth thing that I am not clever enough to think of instead.
Feedback welcome on which one we should prefer, especially from Marco.
smcv
Yes, that's the same situation
Hello, Bug #1051785 in gdm3 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/gdm/-/commit/dc6ab49be2bfdd730a8a7176020217cafc1dbd8d ------------------------------------------------------------------------ d/gdm3.alternatives: Make gdm-smartcard-sssd-or-password the default With the previous default, gdm-smartcard-sssd-exclusive, if a smart card was plugged in and libpam-sss was installed, we would reject attempts to log in with a password. This is the most-hardened choice if smart cards are being used for authentication, but prevents login if the smart card has not been enrolled for authentication and is actually being used for some other purpose such as OpenPGP or X509. Closes: #1051785 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1051785
Hello, Bug #1051785 in gdm3 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/gdm/-/commit/a282369756946506a53b1ec55f8a2009af7c5ba2 ------------------------------------------------------------------------ d/greeter.dconf-defaults: Disable smartcard authentication by default Enabling smartcard authentication has side-effects on other aspects of greeter behaviour if a compatible smartcard happens to be connected: in particular, it disables the user list, resulting in users being required to type their username to log in. Enrolling smartcards to be used for authentication requires sysadmin action, so it seems reasonable to require the sysadmin to take action to enable it after they have done the necessary enrolment step. Closes: #1051785 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1051785
We believe that the bug you reported is fixed in the latest version of
gdm3, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1051785@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated gdm3 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 13 Jul 2025 20:08:32 +0100
Source: gdm3
Architecture: source
Version: 48.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1051785 1096689 1105057
Changes:
gdm3 (48.0-2) unstable; urgency=medium
.
* Team upload
* d/greeter.dconf-defaults: Remove non-functional theming options.
The visual design of the greeter (login prompt) is no longer intended
to be configurable, and in particular the background is no longer
configurable, so none of the background-related settings have any
effect. The greeter also does not use GTK, so changing the GTK
theme has no effect on it.
Remove these options from the default configuration file so that
they will not mislead sysadmins. (Closes: #1105057)
* d/greeter.dconf-defaults: Add some useful example options.
Disabling fingerprint authentication is one of the examples given
in the GNOME System Administration Guide. The steps from that guide
won't actually work as-is on Debian (because we use a different
username for the greeter, #1107944) but we can make it as easy as
possible to do the equivalent.
Meanwhile, disabling smartcard authentication is a way to avoid the
presence of a smartcard having the side-effect of disabling the user
list, and in some configurations also the ability to log in with a
password (#1051785).
* d/gdm3.alternatives: When smart card authentication is re-enabled,
make gdm-smartcard-sssd-or-password the default.
With the previous default, gdm-smartcard-sssd-exclusive, if a smart
card was plugged in and libpam-sss was installed, we would reject
attempts to log in with a password. This is the most-hardened choice
if smart cards are being used for authentication, but prevents login
if the smart card has not been enrolled for authentication and is
actually being used for some other purpose such as OpenPGP or X509.
(Closes: #1051785)
* d/greeter.dconf-defaults: Disable smartcard authentication by default.
Enabling smartcard authentication has side-effects on other aspects of
greeter behaviour if a compatible smartcard happens to be connected:
in particular, it disables the user list, resulting in users being
required to type their username to log in.
Enrolling smartcards to be used for authentication requires sysadmin
action, so it seems reasonable to require the sysadmin to take action
to enable it after they have done the necessary enrolment step.
(Closes: #1051785)
* d/p/gdm-settings-utils-rename-variable-to-fix-build-with-gcc-.patch:
Add patch from upstream 49.alpha.0 to fix FTBFS in C23 mode.
This won't become relevant until gcc 15 becomes the default during
the forky cycle, but is a harmless change while we're uploading anyway.
(Closes: #1096689)
Checksums-Sha1:
dfba5596e42c01ed7df3dbecb752d19cebcd1c86 3208 gdm3_48.0-2.dsc
b9e359e03e6c5273964e159948562315de5071b8 86860 gdm3_48.0-2.debian.tar.xz
a9269b9fa53256868cab293e376974e9ca840170 16401 gdm3_48.0-2_source.buildinfo
Checksums-Sha256:
8eadada57b7f29f20cedfabc95434bf64c8342ac9a33d6d526cac103b51a3ecf 3208 gdm3_48.0-2.dsc
3bacef59fee6fe06ccb15c81e8313fa3a68228f6289b889b518c43cfc5a21242 86860 gdm3_48.0-2.debian.tar.xz
df4bea5c47acc826e0dc12e7bb66ccc80bff15c15d98300b0501a69f5bd01efc 16401 gdm3_48.0-2_source.buildinfo
Files:
24af7805ab175fd3431c620cac0d5e0b 3208 gnome optional gdm3_48.0-2.dsc
3cf84c15def8c2cb1e0c1668eea0b361 86860 gnome optional gdm3_48.0-2.debian.tar.xz
fa6a4aa5f485e9a782cb1574551ce42a 16401 gnome optional gdm3_48.0-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEegc60a5pT6Jb/2LlI1wJnT6zMHYFAmh0MwcACgkQI1wJnT6z
MHZxeBAAweUXi1a/Zy74r8M7tBD6bwuT4y4x9Mhjmn4G+XGbsryvs2qmloCVpkpk
jwHwi18gPb+WaxaNb+bQM1DiSt2io2NncJt3Gkw0UdPq+tfYpzBaLJiJBhl9sgJE
vtnSr/a1iu0SYvUGXXPp3fwQJ3g3jDHtNDlhw/JsTJVKF+g3wdweWXUsKhCOJSzX
PCKXa5FoyiFTxDhiKyRuW0JB4LZU9LyFtc/r+DIEQz0x5MgQ5oxOVIpr/c/P40zZ
2TNUSegDbMI1S/hXk586xuCvDuzDNR0rM5E+ELJRAjiWHPqNMB0r7wVd+d1RPJ70
FU9/Kr0ye/Glh654LvVcGsYNB0BA4u8iBLRFjUawIiZmujk6Q1+rufdmjEQrtGjW
Ep0HaKkaRNkT9+/ovgV7B81OXmZO9lJHfb27x3zES7sLApfNDRwgWEMFXOCUkyXP
OnuERhRMpVP+wLOes/cjaHiKuKGqPgJiJnkptmR9gb9HQgGUB0d6Yw3WMdeHtAbt
tIzzkBAEZo2a7OdGCwPYook9u15Q2PzsXNOmTNsPAoM0c9+dKTFgpAh1rKJp2DdH
iRBiAEywU54VtdmO1Jkzituy5W5A8lfaZKZMy/L8Ps5WRAiHTmVT25KM9Z37aF55
HJPeZRhGMwlIwLTPWAS8jgXy0c6nGi/8R0Ia4BvJv0kHlFK3bTI=
=NwAa
-----END PGP SIGNATURE-----