Hi,

I have configured a Yubikey as an alternative authentication method via pam_u2f by prepending the following line to my /etc/pam.d/greetd file:

    auth       sufficient   pam_u2f.so cue nouserok origin=pam://hostname appid=pam://hostname

This works with any other security key. When I enter my username in gtkgreet, previously, I got prompted for a password. Now, when I have my Yubikey plugged in, after entering my username I see the cue "Please touch the device" (due to the "cue" in the pam.d/greetd line above) and I see a button named "login". Once I _click_ the button named "login", my Yubikey starts blinking and if I touch the Yubikey, I get logged in.

I would prefer if the Yubikey immediately starts blinking (requesting to be touched) once I enter my username and press enter, in the same screen that displays the "Please touch the device" hint. That I have to confirm first by pressing the "login" button seems redundant, as I confirm by pressing the Yubikey. Taking the password authentication as an example, this feels as if I would have to press another confirmation button between entering my username and entering my password.

Also it's annoying that I can't confirm the "login" button via my keyboard, I have to use my mouse. At least using "tab" to select didn't work, maybe there are some GTK shotcuts that I could use to select buttons by keyboard that I don't know.

Anyway, I'm not sure if this is easily solvable, because I assume the code is written in a general way, not assuming as specific pam.d login method. For those, where some text field input is required (like passwords or OTP via pam_google_authenticator.so), a confirmation of the text input makes sense. Also it makes sense to have it when pam_u2f.so is used as a second factor and not a standalone login method, as then the user needs to enter a password first anyway. But purely from a user point of view, I think for my specific use-case the user experience could be improved, so I thought I might point it out.

I haven't tried making any screenshot, as I would first need to figure out how to do it in gtkgreet, but if you think it's necessary I could try to figure it out. Not sure how you could try to reproduce the behaviour without a security key.

Cheers,
Michael Eliachevitch

The problem is not a redundant login button on its own. In PAM, an info 
message is no different from a password question, and must be answered 
for the flow to proceed. If one automatically answers info and error 
messages, the user will not get a chance to read them, and they 
sometimes contain important information.

What one could do is make a change so that the last N info messages are 
added to a list of messages that remain visible (handling the case where 
multiple messages arrive in sequence, which is perfectly valid), and 
only then is the conversation automatically answered.

Requiring mouse to login is a separate issue. The focus should be 
fixable so that enter proceeds.

Patches welcome. :)

Best regards,
Kenny Levinsen

On 2023-03-13 at 17:17 +01, Kenny Levinsen <kl@kl.wtf> wrote:

> The problem is not a redundant login button on its own. In PAM, an info message
> is no different from a password question, and must be answered for the flow to
> proceed. If one automatically answers info and error messages, the user will not
> get a chance to read them, and they sometimes contain important information.

By the way, the "gtklock" screen locker, which is based on gtkgreet scree-locker, handles this in a different way and I'm not sure whether I find it better or worse. I also configured pam_u2f as a sufficient login method in /etc/pam.d/gtklock. Nonetheless, it gtklock _always_ shows me text field for the password, even if I have my yubikey plugged in. However, then I can just press enter to send an empty password and then my yubikey blinks, and when I touch it I get logged in. At least that requires no mouse input and just shows all messages together. But, even if I enter a correct password it still asks for the yubikey input, though I can just unplug it to proceed. But that should go on the gtklock issue tracker.

> What one could do is make a change so that the last N info messages are added to
> a list of messages that remain visible (handling the case where multiple
> messages arrive in sequence, which is perfectly valid), and only then is the
> conversation automatically answered.

Sounds sensible

> Requiring mouse to login is a separate issue. The focus should be fixable so
> that enter proceeds.

That would be helpful. I.e. if there's a password prompt, the focus should still be on the text field, but if there's non, it could be on the login button directly.

> Patches welcome. :)

Let's see if I find the time. I never looked at any greet/gtkgreet code yet, have never done any GUI programming, never really programmed C, only some C++ a couple of years ago. But the advantage of your greeters is that the codebase is quite small, so should be do-able, but requires some initial commitment for me. Would be happy at hints where to get started, e.g. what files and functions to look at.

Cheers, Michael

On 4/4/23 10:55, Michael Eliachevitch wrote:
> Would be happy at hints where to get started, e.g. what files and 
> functions to look at.

gtkgreet_setup_question in gtkgreet.c and window_setup and 
window_setup_question in window.c would be the primary places to look 
for how info and error messages are handled and displayed.

You might be able to "borrow" changes from gtklock depending on how much 
it has been rewritten.