2

I put the following settings into my SSH-enabled remote machines, with the hope that I can launch GUI programs through SSH sessions.

# These settings shall go to `/etc/ssh/sshd_config`.
X11Forwarding yes
X11UseLocalhost no
AllowAgentForwarding yes
X11DisplayOffset 10

I use Windows 10 machines with Xming and WSL, locally. On all local+remote machines, I have set export DISPLAY=0:0 in my ~/.bashrc, which matches the default setting for Xming that are running locally.


Yet, it does different things depending on the host:

  • If the host is a Linux machine, when I use ssh -X user@host to connect and then fire gvim, the GUI is brought to the local machine and all is well;
  • If the host is a WSL-running Windows 10 machine, while ssh -X user@host does get me access to the command line of the remote machine, gvim will instead fire up a GUI session on the remote machine instead.
    • If I further close the Xming on the remote Windows 10 machine, Gvim will complain that it "cannot open display". This it the same error message when trying to fire gvim on the remote machine locally(Remote Desktop Connecting into that machine).
    • On the remote Windows 10 machine, I use this command to host the server: sudo service ssh start.

Question: please advise the proper settings for the Windows 10 machine, so that I can hook up GUI programs via X11. Thx!


More debugging info

Excerpts from ssh -v -X user@remote_server:

  • From the Linux remote machine:
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
Welcome to Linux Mint 18.1 Serena (GNU/Linux 4.4.0-53-generic x86_64)
:: >>Linux-remote<< ::~>>echo $DISPLAY  
localhost:12.0

After further testing, this number shall increase as I open up new SSH sessions with the Linux remote.

  • From the WSL-Windows-10 remote machine:
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.4.0-17763-Microsoft x86_64)
:: >>WIn-WSL-Machine<< ::~>>echo $DISPLAY 
0:0

Repeated "echo-ing" of the $DISPLAY in the SSH session with the remote WSL-Windows machine kept showing the same 0:0.

PS: I have been testing the X-forwaring on the same local machine, with an Xming server running at local port 0:0. Such Xming server has been happily accommodating GUI from its "local" Windows WSL shell/system, as well as the Linux machine. It now bugs me that the remote Linux machine should be using a port localhost:12.0

enter image description here

6
  • Remote the display export from your login files, and simply ssh -Y user@remote – ivanivan Apr 29 '19 at 17:19
  • @ivanivan. Thanks for the -Y flag. Yet, how to properly "remote the display export from my (local) login files"? – llinfeng Apr 29 '19 at 19:31
  • Sorry, typo. Should be "remove the display export from ..." – ivanivan Apr 29 '19 at 19:38
  • I removed all export DISPLAY=0:0 lines from my ~/.bashrc (and fish.conf). Nothing changed yet ==> I am restarting the WSL-Windows remote now. – llinfeng Apr 29 '19 at 19:47
  • Restarted the remote WSL-Win machine, and same thing: with the local@remote Xming server running, gvim won't throw an error but will drop the GUI window at the remote Windows desktop; shutting down the Xming server running at the remote machine shall leave me with the same error. – llinfeng Apr 29 '19 at 19:57
2

I met the same problem and I solved it by setting "DISPLAY=localhost:0.0" instead of "DISPLAY=:0.0" in WSL. Refer to, https://unix.stackexchange.com/questions/57138/why-does-my-x11-forwarding-attempt-fail-with-connect-tmp-x11-unix-x0-no-such

0

I've seen lots of examples using resolv.conf but it never worked for me.

I set DISPLAY in my .bashrc as export DISPLAY="$(/sbin/ip route | awk '/default/ { print $3 }'):0" and it works perfectly.

I can also now get x11 apps in colour: SOLVED: x11 apps in WSL/ubuntu are black and white only

Note this is with WSL 2, WSL 1 may be different.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.