Setting a custom keyboard layout in Wayland does not apply when SSH-ing

Question

I recently upgraded my Ubuntu system from 20.04 (Xorg) to 22.04, and switched to Wayland. This upgrade created several unexpected challenges for my environment, particularly in terms of configuration. After the necessary troubleshooting and adjustments, I've become more familiar with the nuances of Linux, however, I've hit a brick wall and cannot figure this out. No forum, SO question, or reddit post on this topic applies to my case.

Context:

1. I'm looking to establish a consistent custom keyboard layout both for regular local use and for SSH sessions into my machine.
2. Wayland relies on xkb for keyboard configurations or Sway. I've tried using both the input directive in the Sway config and the setxkbmap command to ensure compatibility with xwayland apps.
3. Logging in directly to my machine (e.g., via TTY) works perfectly with the custom layout, but this is not the case when I SSH into it. For some reason, regular dvorak is being used during SSH sessions, this is weird since it should either be QWERTY or my Custom layout, but for some reason its neither?
4. I'm also considering using mosh, which, to my knowledge, doesn't support XForwarding that would be needed to have xwayland working and in terms setxkbmap. Of course I still have gaps in my knowledge so I have no idea if what I am saying makes any sense

Configuration: Here is a snippet from my Sway config:

input * xkb_layout custom
exec_always setxkbmap custom

How can I ensure my custom keyboard layout is consistently applied, especially for non-interactive shells or SSH sessions?

Thank you for your insights and suggestions!

Answer 1

You wrote:

Logging in directly to my machine (e.g., via TTY) works perfectly with the custom layout, but this is not the case when I SSH into it.

You expect the keyboard config on the server side to be applied when you log in via SSH. This is not how the things work.

SSH does not transmit any keyboard-related codes to be interpreted as such on the remote side. It transmits bytes. The only processing between sshd and the program running on the server (e.g. an interactive shell) is line discipline (in case of allocated TTY) or nothing (otherwise).

Everything related to the keyboard is done locally on the client side, the local config matters. Additionally the local terminal (or terminal emulator) may translate some keyboard input before it gets to the SSH client (and there is line discipline in between, mostly transparent though); and the client itself (or e.g. PuTTY which is an SSH client bundled with a terminal emulator) may do some translation. But once data gets to the remote side, it's not treated as keyboard input.

The server's keyboard config does not matter because you're not using any keyboard on the server.

In other words:

• When you run a non-GUI program (like a shell) in a terminal (or in a terminal emulator with GUI), it gets input from the keyboard digested by several layers; the config in question is (or at least may be) one of the layers.

• When you run a non-GUI program (like a shell) on a remote server via SSH, it gets input from your local SSH client with little (if TTY is allocated on the server side) to no modification (if no TTY). The input from the client is transmitted as a byte stream. See this answer of mine to see that even "signals" are transmitted this way.

  • But the local client program itself is a relay that gets its input locally from the local keyboard, so digested by several local layers. Some config similar to the config in question is (or at least may be) one of the layers, but this is a local config, client-side.

Solution: set a (or the) custom keyboard layout on the client side.