In two previous posts I wrote about how to use RDP and VNC to access the graphical desktops of the virtual machines on my headless workstation. Both have in common that the desktop of the remote virtual machine is put into a window on my client machine. That is great for many purposes and when used at the resolution of the screen connected to my client machine in full screen mode, it is almost like working directly on that machine. Also, the whole desktop with all applications running on it can just be ‘minimized’ to the dock when not needed for a while. For Linux virtual machines, there’s a third option that is even cooler for some use cases: Remote X over SSH!
The idea behind remote X over SSH is that the application itself runs in the virtual machine on the workstation. It doesn’t use the X-server on the virtual machine, i.e. the desktop there, but all commands to build and change its window(s) are sent over SSH to the client machine’s X-server. So all computationally expensive operations are done on the workstation while the graphical front end is managed by the client.
Sounds complicated to set up but it’s actually straight forward: Just add ‘-X’ (uppercase!) to the SSH command to access the server from a shell. In the ssh shell the remote application can be started on the command line and the window magically appears on my notebook’s screen! With a fast connection between my notebook and the workstation, it looks and feels just the same as if the application was started on the notebook. In the case of the Eclipse development environment shown in the screenshot, the window reacts more smoothly than if I ran it in a local virtual machine on the notebook. It’s a bit of a heavy program.
While I had no problems running Eclipse remotely this way, I noticed that some GTK apps on a remote Ubuntu 20.04 would not open their windows on my client notebook. Turns out that this is an Ubuntu 20.04 issue that can be fixed with the following command in the ssh shell:
dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY
As I run my workstation without a screen attached, X-forwarding over SSH is also the thing to do to access graphical programs running on the workstation directly rather than in a VM on the workstation. RDP and VLC can’t be used on the host as there is no desktop to export over the network if no monitor is attached.
One caveat: While X-forwarding over SSH works great in the local network, it’s totally unusable over the Internet. Bandwidth requirements and I guess especially latency are crucial. In that regard, VNC is the only choice in my setup.
3 thoughts on “Remote Visual Computing – Remote X over SSH – Workstation Power At Home – Part 7”
Try adding compression to your SSH ( `-C` ); that way the X bandwidth requirements drop significantly.
Just gave it a try and indeed, the bandwidth requirements are much lower! Thanks!
I use ssh -X quite a bit and worry that it’ll be damaged to some extent by Wayland but haven’t looked into at all. This is slightly encouraging but not completely reassuring:
“What about network transparency?
The X11 protocol was designed around running graphical apps across the network. While some people use this feature, it’s far from common. Wayland drops this requirement as a way to greatly simplify its architecture.
There are other ways to share graphical sessions and applications across a network. Wayland also permits running an X11 server inside itself, so you also always have the option of just running X11 clients on top of the server.”
Comments are closed.