2023-02-08

X11 Forwarding woes

Here is a very quick post. It's for a very common/annoying Linux X11/Forwarding quirk which I previously forgot what the solution was and decided that I would add it into my blog as a reference

Background:

When working on my Development laptop remotely with a LiveUSB (for either ripping audio or video content or using it as a dev environmenmt for my recent study), I found that having to setup/install packages locally with tge laptop keyboard/trackpad was anoying when having to constantly switch (physically) from main desktop to the laptop. Thanks to SSH most setup and interactions with the machine can be done from another machine.

The Problem:

Having SSH access is nice, but having access the locally installed browser and other apps displayed locally (via X11Forwarding) is even better (purely so I can avoid having to transfer downloaded content).

Some applications wil just work without changing anything, others (read: Firefox) require a little more persuaion to work.

This is kind of what it looks like out of the box on the host (with X11 Forwarding enabled in sshd and configured on the client SSH application):

kubuntu@kubuntu:~$ firefox &

[2] 17790 

kubuntu@kubuntu:~$ PuTTY X11 proxy: Unsupported authorisation protocol

Unable to init server: Broadway display type not supported: localhost:10.0

Error: cannot open display: localhost:10.0


[2]+  Exit 1                  firefox

kubuntu@kubuntu:~$


The solution
:

For me it was quite simple (not sure if this will work for others though so YMMV).

Update the $DISPLAY environment variable:

export DISPLAY={{ x11_server }}:0.0


Where {{ x11_server }} is the hostname or IP address of the X11 Server (XLauch or whatever).

There, now I shouldn't forget this ever again :-D


Additional information:

  1. This solution also seems to work inside individual screen sessions.
  2. Source of the solutiuon (#2 in the list) was rediscovered at https://stackoverflow.com/questions/61221498/x11-forwarding-works-on-ubuntu-using-windows-10-cmd-line-ssh-only-after-first-us

 
Google+