KB: Keyboard problems when accessing SecureCRT via VNC/RDP on Linux?

[jdev]

Introduction
A very small number of individuals have recently reported that when they attempt to access SecureCRT (running on Linux) through an RDP/VNC connection, the keyboard mapping is incorrect. Meanwhile, when accessing SecureCRT directly on the Linux machine (not through a remote RDP/VNC connection) the keyboard works just fine.

If you find yourself in a similar situation, here's some background info and steps you can consider taking to resolve the problem.

Symptoms
Here's a description of what has been reported:

• Running SecureCRT natively on the Linux machine (Ubuntu 16.10, for example), there are no problems with the keyboard working as desired.
• When connecting with an RDP/VNC client to the Linux/Ubuntu machine and accessing the SecureCRT app remotely, keyboard activity delivers unexpected results. As examples:
  • Typing "asdf" comes out as "abfh" (or something else completely foreign)
  • Typing "qwerty" comes out as "c.gvn".
  • Typing "cisco" might come out as "dlbdz", Command+Tab might come out as the number "5", and the Delete button might not work.
• When launching SecureCRT from the command line, the following error is displayed: "Qt: XKEYBOARD extension not present on the X server."

Cause:
This problem is caused by RDP/VNC client/server implementations that are not implemented/configured to support the XKEYBOARD extension.

• SecureCRT for Linux and macOS uses Qt libraries.
• Qt version 5 makes use of the XKEYBOARD extension.
• Some RDP/VNC server/client apps don't properly implement (or are not currently configured to enable) the XKEYBOARD extension, on which Qt5 apps rely.
• Qt is aware of the issue; details available here: https://bugreports.qt.io/browse/QTBUG-44938
• More info here: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=814959

Possible Fixes:
While SecureCRT cannot force an RDP/VNC client/server implementation to support the XKEYBOARD extension that Qt requires, there are some steps you can take to potentially resolve the problem:

• Update your RDP/VNC server implementation to one that supports/enables the XKEYBOARD extension.
  • One individual switched from using tightvncserver to vnc4server, and the problem went away for them.
  • In another case, an individual installed vnc4server, but the problem remained until tightvncserver was removed.
  • One online resource suggests that TurboVNC is an implementation that supports the XKEYBOARD extension.
• Try using VNC as the remote access protocol instead of RDP.
• Try running the following command prior to launching SecureCRT from the command line: export XKB_DEFAULT_RULES=base