Smartcard authentication and remote (RDP/VNC) sessions

[thomas.walker]

Not sure whether this is the best category for this, so recommendations welcome…

I’ve been successfully using GDM and Gnome with smartcard (Yubikey PIV) based authentication and PKINIT for some time now. I use a system-wide dconf profile and locks to require users to use the Yubikey (enable-smartcard-authentication=true and enable-password-authentication and enable-fingerprint-authentication=false) and require that screen lock is enabled and set for a reasonable timeout. That all works wonderfully.

But in the hybrid work situation that is common these days, users often want to connect to their systems remotely, whether via XRDP, VNC, NX, etc. The initial connections for these methods work fine, as they’re each using their own auth method that doesn’t support (let alone require) a smartcard that obviously can’t easily be presented remotely. But after the specified timeout, Gnome dutifully locks the screen and it can’t be unlocked again because of the aforementioned dconf settings and locks and the inability to plug in the smartcard when not actually in front of the system.

I don’t want to simply turn off the screen lock requirement, as that is necessary for the “I’m sitting in front of the system” scenario, but there appears to be no way to control any of these settings on a per-session basis. I was looking at using pam-script in gdm-smartcard to permit fallback to another auth option for a remote session but, as pam seems to be getting called by gdm-session-worker, tying it back to a specific systemd/logind “session” to determine “local/remote” isn’t exactly trivial.

I’m wondering whether anyone else has tried to tackle this problem before or has any ideas?

Thanks in advance!

[thomas.walker]

The best I’ve been able to come up with here is to have a little xdg autorun script that checks the current session properties (Remote=yes, Service=xrdp.service) and runs gnome-session-inhibit --inhibit idle to prevent lock on idle. That doesn’t impact other (local) sessions and doesn’t do anything to prevent the user from manually locking the xrdp “screen” (not realizing that they won’t be able to unlock it), but is hardly ideal. It would have been a little less hokey if I could have called gnome-session-inhibit in xrdp’s startwm.sh or in the Xsession startup, but there isn’t a Gnome SessionManager yet to issue the command to.

It would really be nice if dconf /gsettings could differentiate between local and remote sessions for things like screen lock, whether a smartcard was required, etc.