0

From my Windows box, I connect to my Linux box using VNC viewer/server.

On the Linux box, when my session times out, and after the lock screen kicks in, if I subsequently try to unlock using the gui, over VNC, I seem to be permanently "locked out" without the ability to enter any text at the password prompt. More specifically, it appears as though some stream of Enter characters is being constantly streamed over VNC, triggering the login prompt to think the user is constantly entering a 0-length password: notice the "Authentication error" statement in the attached screenshot, revealing that the login screen thinks something has been entered. Moreover, if I stress-test here, by typing quickly, one or two of the "hidden character" symbols will appear before quickly disappearing again. All the while, the "Authentication error" is perpetually displayed.

The workaround I've found to this situation is to log in directly to the Linux box and run this script:

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done

...where that number, 2, is my "session-id". The script has the effect of dismissing the lock screen (within one second) whenever it appears - not exactly the best solution, but better than a perpetual lockout with an inability to enter a password.

Why is this necessary? Can someone explain what's going on with VNC viewer/server, or the lock screen on the Linux box, or any other related software, and why there appears a constant stream of Enter being sent through VNC specifically to the Linux login screen (or whatever else is going on to make the lock screen continually report "Authentication error" as though an incorrect password was supplied)?

Note that when I'm past the lock screen, at a bash shell, there doesn't seem to be any undesired keystrokes sent - i.e. I can type, execute commands, etc. without interference from any unintended keystrokes.

Related(?) question: If this is not cluttering the subject: note that the script I run is in the foreground, i.e.:

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done

...not...

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done &

...if I try the backgrounded version of the script, it has a onetime-only effect, i.e. the lock screen is only dismissed the first time run, but never thereafter, vs. the foreground version of the script, which seems to keep the lock screen away perpetually. Why does it make a difference, in this context, whether the workaround script is in the background or foreground?


Env details:

$ uname -a
Linux linuxbox 5.3.11-100.fc29.x86_64 #1 SMP Tue Nov 12 20:41:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

.

$ vncserver -list

TigerVNC server sessions:

X DISPLAY # PROCESS ID
:1  2958

.

$ loginctl list-sessions
SESSION   UID USER    SEAT   TTY
      2  1000 user    seat0  tty2

1 sessions listed.

enter image description here

2

Gnome seems to be aware of this bug. You can see the evolution of the issue here https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2196

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.