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


$ 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:

:1  2958


$ loginctl list-sessions
      2  1000 user    seat0  tty2

1 sessions listed.

enter image description here

  • Has this issue been resolved? I am facing it while connecting to a Linux server from a Mac client. A workaround is, of course, to disable the screen lock indefinitely from the Power settings the first time one logs in. But, it's not an elegant solution.
    – SKR
    Nov 30, 2023 at 11:23
  • @SKR - I'm afraid I've moved away permanently from the environment where I logged in to the Linux PC by VNC. As of the last time I was working in that environment, the only solution I ever found to the problem was the perpetually-running loginctl unlock-session script.
    – StoneThrow
    Nov 30, 2023 at 17:50

1 Answer 1


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .