[Remote-SSH] X11 forwarding in integrated terminal won't work

[roytseng-tw]

• VSCode Version: 1.34.0-insider
• OS Version: macOS Mojave 10.14.4

Steps to Reproduce:

1. Connect to a remote server by ssh using Remote-SSH extension
2. Open a integrated terminal (this opens a terminal on the remote server)
3. Commands like: xeyes, eog won't work

Does this issue occur when all extensions are disabled?:
If manually ssh to server in integrated terminal, x11 forwarding works fine.
I think maybe DISPLAY variable is not set properly in the failure case.

[wrobelda]

I logged in with regular ssh client, checked the DISPLAY variable it set automatically and added it by hand to my launch.json configuration:

environment": [ {"name" : "DISPLAY", "value": "localhost:11.0"}],

Works flawlessly. However, it should be done automatically just as the regular ssh client does it. I also noticed that the built-in ssh terminal doesn't source the .profile file, which I suppose may be related.

EDIT: correction, I need to have a separate ssh terminal running in the background with X11 forwarding enabled, otherwise I am getting the connection refused error.

[PALuczak]

VSCode Version: 1.34.0-insider
OS Version: Windows 10 1809 (17763.475)
I also have this issue. I have set ForwardX11 and ForwardX11Trusted in my ssh config and when connecting through a normal terminal x11 is forwarded and the DISPLAY variable is set, but then I use VSCode these settings are not applied. This is an issue especially when trying to do scientific computing in Python, since I cannot see the plot windows from e.g. matplotlib.

[therealkenc]

Some more background. A common scenario is having the server in a local headless VM. Setting up X11 forwarding in ssh config as suggested in the closed #151 issue is not sufficient, because the "normal" (equivalent of) ssh -X doesn't happen inside VS Code Remote; meaning, there is no local X11 socket on the remote side. You have to use something like wrobelda's workaround and piggyback off an existing socket.

This problem is fairly acute in the vscode-cpptools ref #45 case. The default launch.json assumes an external terminal (x-terminal-emulator via the terminal.external.linuxExec setting), and needless to say that fails.

So the problem isn't just that you can't run xeyes from the integrated terminal per the OP -- which I can imagine being perceived as an academic nice-to-have but a not showstopping use case. You can always open an external term and ssh -X if that's how you wanna roll. In the remote vscode-cpptools case the lack of X11 ssh forwarding is causing some material grief.

[EzioZz]

I find another method which can temporary solve this problem. To begin with we should start a separate terminal which can use X-server flawlessly. Then we run the command export DISPLAY=localhost:11.0 in the integrated terminal in vscode-remote. "11.0" should be same as the parameter in the separate terminal .

[VishalDhayalan]

I find another method which can temporary solve this problem. To begin with we should start a separate terminal which can use X-server flawlessly. Then we run the command export DISPLAY=localhost:11.0 in the integrated terminal in vscode-remote. "11.0" should be same as the parameter in the separate terminal .

I've tried this, it doesn't work. On my windows laptop, I have putty with X11 setup running an SSH terminal connection to my raspberry pi 3B+ and an Xming server. Through putty X11 works without problems. But while still running these both in the background if I do export DISPLAY=localhost:0.0 in integrated VC Code insiders terminal which has remote-ssh connection to my RPi and then try something like Tkinter by importing it and doing root = Tk() which should show the blank tkinter window that is created, but it doesn't and says cannot connect to DISPLAY=0.0 .

The same works perfectly in the putty ssh terminal though... Did anyone solve this?

[psolyca]

Another way to get X11 Forwarding for all integrated shells is to set "terminal.integrated.env.linux": {"DISPLAY":"localhost:10.0"},
But you always need a SSH session in background to enable X11 forwarding as @wrobelda said.

[MikeZhu92]

I was trying to figure out the same issue and it turns out I trust OpenSSH too much.
According to their document:

Not supported
The following configuration options are not available in the OpenSSH version that ships in Windows Server 2019 and Windows 10 1809:

• X11DisplayOffset
• X11Forwarding
• X11UseLocalhost
• XAuthLocation

Epic.

ref link:

[t-schroeder]

I tried to create a workaround by making remote.SSH.path point to a batch file that contains

bash -c "export DISPLAY=localhost:0.0; ssh %*"

If I then kill the remote vscode server and restart it, DISPLAY is at least set to some value, but that doesn't help because the original connection that set it has been closed.

Maybe on Windows 10 it could work if you add -M to the ssh call and set ControlMaster and ControlPath in your ssh config so that the first SSH connection gets reused by the later ones. I couldn't get it to work on my Windows 7 machine.

Edit:
I had to change remote.SSH.configFile from "C:\Users\..." to "/C/Users/..." because I use the bash.exe from Git for Windows.

[wenqihuang]

My solution is to write DISPLAY env var to .zshrc on my server. Of course you can use your own sh which is used in vscode(for example: .bashrc for bash).
here is the steps:

1. Add export DISPLAY=localhost:10.0 to ~/.zshrc;
2. Add ForwardX11 yes to your ssh configuration file in vscode.
3. start a x11 farwarding ssh at background.

The reason why x11 forwarding always fails is that the DISPLAY is not set properly. To my understand vscode only source .xxshrc when starting an terminal. So by adding DISPLAY env var to .xxshrc can solve it.

[joelspadin]

I wrote an extension that automates the workaround wrobelda and EzioZz found: https://marketplace.visualstudio.com/items?itemName=spadin.remote-x11

When you open a remote SSH workspace, it starts up another SSH connection in the background with X11 forwarding enabled, grabs the DISPLAY out of that, and adds it to VS Code's environment.

I couldn't find any way to re-use the Remote SSH extension's authentication, so it only works with public key authentication. Having this built in to the Remote SSH extension would be much nicer.

[gretzteam]

I tried every solution mentioned here with no success. External terminal works, but from vscode, even using the same display, I would get cannot connect to DISPLAY=xxxxxxx.

What did work is opening a vnc session and put the display number in my .cshrc as:
setenv DISPLAY :33
where 33 is the vncserver display number.

Since VcXserv was going to be another window anyway, to me this is equivalent...

[tautomer]

Public key authentication was disabled on our cluster by the administrator, so @ChaosinaCan's extension is not working. However, by manually repeating what is done in the extension, X11 forwarding will work in VS Code. Connect to the server manually in a terminal, grab $DISPLAY and export it in VS Code terminal.

[ashish5679]

I wrote an extension that automates the workaround wrobelda and EzioZz found: https://marketplace.visualstudio.com/items?itemName=spadin.remote-x11

When you open a remote SSH workspace, it starts up another SSH connection in the background with X11 forwarding enabled, grabs the DISPLAY out of that, and adds it to VS Code's environment.

I couldn't find any way to re-use the Remote SSH extension's authentication, so it only works with public key authentication. Having this built in to the Remote SSH extension would be much nicer.

@ChaosinaCan Thanks a lot. You saved my day, it works flawless with Key based auth. That should be integrated in ssh remote plugin hopefully.

[ychechik]

Another idea: if one builds a full X server for vscode, together with the drag-n-drop file transfer and the integrated terminal- this would be the only program anyone will ever need for working remotely!

[wrobelda]

Another idea: if one builds a full X server for vscode, together with the drag-n-drop file transfer

This can be already done using guacamole.

[sleighsoft]

I would love to have this working in VSCode's Remote SSH extension!

[xiaqian369]

@ChaosinaCan Sorry for bothering you, I can work flawlessly with a new session by SecrueCRT or PuTTY in background like @wrobelda, but if I close the SecrueCRT or PuTTY, using your extension, it does not work, the failure info is "Could not connect to any X display.". Could you please provide a detailed config instruction on your https://marketplace.visualstudio.com/items?itemName=spadin.remote-x11 page? like how to config in vscode, how to config in remote-ssh computer, does your extension need to install in remote machine? etc.

[joelspadin]

@xiaqian369 I just published an update with improved error logging and some troubleshooting steps in the readme. If you still can't get it working, please use my extension's issues page. Thanks!

[mswarrow]

Setting DISPLAY=localhost:0.0 on Windows solved this for me. I noticed that when I connected to a remote using Git Bash everything worked, but when I used Windows cmd (which is actually used by the extension judging from its logs) - nothing. It looks like Git Bash sets DISPLAY variable implicitly. So, I tried to set it from cmd:

> set DISPLAY=localhost:0.0
> ssh my-remote

and it worked.

[zebraone100]

I have an observation that probably goes to the heart of this problem. I'm not an expert in the ins and outs of ssh, but from the following observations, I have a hypothesis. When I connect to my virtualbox install of ubuntu from VSCode running in windows 10 and I run the following command:

zebraone@popcorn:~$ w
 17:28:14 up 1 day, 20:41,  0 users,  load average: 0.01, 0.01, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
zebraone@popcorn:~$

In other words, it doesn't show that anybody is connected. Shouldn't it, at least, show that I'm connected?
but, after starting putty with X11 forwarding enabled and running in the background, I get:

zebraone@popcorn:~$ w
 17:34:34 up 1 day, 20:48,  1 user,  load average: 0.04, 0.04, 0.01
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
zebraone pts/2    10.0.2.2         17:34   24.00s  0.06s  0.06s -bash
zebraone@popcorn:~$

It's as if the integrated terminal, or VSCode isn't actually connected, or at least, not in a persistent way. I hypothesize that this is why we need the background process of putty.

With putty running in the background, the following works, and successfully opens the GUI text editor, gedit:

zebraone@popcorn:~$ export DISPLAY=:10.0
zebraone@popcorn:~$ gedit

I suspect that the output is going through the background putty connection (it is the only one that is addressable?) and not the VSCode connection/non-connection (because it appears as if it doesn't actually exist).

thoughts???

[mswarrow]

@zebraone100, have you tried setting DISPLAY=localhost:0.0 on your Windows host? (Note that it's 0.0) I ran w command on my remote machine as you suggested, it showed 0 users, but I could open GUI on the remote (e.g. xclock). But it worked only with DISPLAY variable set on host.

[tazerdev]

What mostly works for me (VS Code version 1.47.0):

1. On Windows client1, install xming (or vcxsrv)
2. Set user's environment variable to DISPLAY=localhost:0.0 (as @mswarrow pointed out)
3. Launch xming/vcxsrv
4. Launch VSC and create a new Remote SSH session to server1 specifying ssh -Y user@server1 when prompted
5. Verify display variable on server1 was set correctly:

   $ echo $DISPLAY
   localhost:10.0

6. Launch xterm and the window appears on client1
7. Disconnect the Remote SSH session

Now, I go to client2 and login using PuTTY with X11 Forwarding and check the display variable:

$ echo $DISPLAY
localhost:10.0

And if I run xterm it shows up on client2's desktop. That's great.

However, if I'm still logged in on client2 and start a new Remote SSH session from client1 and check the display variable I see it's not set correctly:

$ echo $DISPLAY
localhost:10.0

sshd offers 10.0 to the first X-session, 11.0 to the second, and so forth. Since this is the second X-session it has the wrong display set (should be localhost:11.0) and when I launch xterm it comes up on the wrong client2 instead of client1! VSC seems to be caching this somewhere and ignoring it on subsequent connections. I can verify by disconnecting VS Code, opening up PuTTY on client1 with X11 Forwarding and see that it gets localhost:11.0.

The big problem here is on a multi-user system I don't know which DISPLAY# I'm going to get. Might be 10.0 most days, but it could be 23.0 depending on how may people have X-sessions open.

Is there a method of preventing this variable from being cached? I'm not sure if it's happening client-side or server-side.

[tazerdev]

Per this issue comment from @roblourens the caching is happening on the remote server and is persisted between sessions:

Side note, since I had forgotten this: We only discover the environment once then cache it for the rest of the server's session. If you change your dot scripts and want to see that change reflected when you open a new vscode window, you will have to restart the remote server with the command "Kill VS Code Server on Host".

Using the aforementioned kill command results in the desired behavior if not intuitive. Having a feature/setting to either not cache the DISPLAY variable, or re-read it, and/or a setting to kill the remote server on disconnect automatically would be ideal.

Note: The remote server does shut down automatically, eventually, but the behavior until it does is non-intuitive for those in my situation.

[zhqu1148980644]

Any updates?

[AIXruth]

I had a Xming-Server V6.9.0 running on my windows desktop. All common X11-apps (xclock, xeyes, xterm, ...) worked like a charm, but not VSC. I found out that the old Xming version has a missing feature or bug. As the new version is not for free anymore, I tried VcXsrv and all is fine now. If your X11forwarding works, you won't need any additional settings or configuration, just type
code

[RadionovM]

I get "Failed to get DISPLAY: Error: Invalid cygwin unix socket path" while connecting, using Remote X11. If I set DISPLAY on server manually x11 forwarding works. But Remote x11 cant set it

[cognitiveRobot]

I wrote an extension that automates the workaround wrobelda and EzioZz found: https://marketplace.visualstudio.com/items?itemName=spadin.remote-x11

When you open a remote SSH workspace, it starts up another SSH connection in the background with X11 forwarding enabled, grabs the DISPLAY out of that, and adds it to VS Code's environment.

I couldn't find any way to re-use the Remote SSH extension's authentication, so it only works with public key authentication. Having this built in to the Remote SSH extension would be much nicer.

Hello @joelspadin Thanks for your extension. When I try, it gives me a timeout error as below.

However, it works, if I connect from an external terminal with -X and then export DISPLAY=localhost:11.0 on vscode integrated terminal.
Can you please help? Thanks.

[MortenGuldager]

Being in linux it might be simpler, but I made it work with this lille hack. In your ~/bin folder make a file called ssh-with-fixed-DISPLAY, with the following content:

#!/bin/bash
DISPLAY=:0.0 exec /usr/bin/ssh -X "$@"

Make it executable.

Then in your settings.json add or edit the key saying remote.SSH.path, make it point to your ssh-with-fixed-DISPLAY. Mine looks like:

    "remote.SSH.path": "/home/mogul/bin/ssh-with-fixed-DISPLAY",

Reconnect and enjoy xeyes

[roblourens]

Implementing this in #589

[str-eat]

I found it just as easy to add export DISPLAY=:11.0 to my .bashrc

FYI