24

I am using Open SSH (OpenSSH_6.6.1p1, OpenSSL 1.0.1i 6 Aug 2014) in Windows 8.1. X11 Forwarding does not appear to be working. The DISPLAY environment variable does not appear to be set.

For example, if I use BitVise or Putty to connect, and run env, I see:

[marko@vm:~]$ env
XDG_SESSION_ID=6
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.1.174 61102 22
SSH_TTY=/dev/pts/0
USER=marko
MAIL=/var/mail/marko
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/home/marko
LANG=en_CA.UTF-8
NODE_PATH=/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
SHLVL=1
HOME=/home/marko
LANGUAGE=en_CA:en
LOGNAME=marko
SSH_CONNECTION=192.168.1.174 61102 192.168.1.64 22
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=localhost:10.0
_=/usr/bin/env

If I instead use OpenSSH (ssh -X marko@vm):

[marko@vm:~]$ env
XDG_SESSION_ID=8
TERM=cygwin
SHELL=/bin/bash
SSH_CLIENT=192.168.1.174 61150 22
SSH_TTY=/dev/pts/1
USER=marko
MAIL=/var/mail/marko
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/home/marko
LANG=en_CA.UTF-8
NODE_PATH=/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
SHLVL=1
HOME=/home/marko
LANGUAGE=en_CA:en
LOGNAME=marko
SSH_CONNECTION=192.168.1.174 61150 192.168.1.64 22
XDG_RUNTIME_DIR=/run/user/1000
_=/usr/bin/env
Improve this question
5
  • 1
    Might be an obvious one, but I can't tell for sure from your post - do you actually have an X server installed on Windows, e.g. following bitvise.com/ssh-x11-forwarding ?
    – TessellatingHeckler
    Jun 3, 2015 at 3:57
  • 1
    Yes, I have Xming X Server (straightrunning.com/xmingnotes)
    – abendigo
    Jun 3, 2015 at 18:20
  • Have you - just to test things - tried the same with PuTTY? If not, I suggest trying with that, and seeing if it works there.
    – polemon
    Jun 11, 2015 at 18:44
  • 2
    yes, it works in putty.
    – abendigo
    Jun 11, 2015 at 18:47
  • I'm checking my Windows VM right now. It might be as simple as checking what kind of variables PuTTY sets to get this working. I'll add a reply in a couple hours.
    – polemon
    Jun 11, 2015 at 19:10

5 Answers 5

Reset to default
26
+50

Have you set DISPLAY environment variable on the client? I'm not sure which shell you are using, but with Bourne shell derivative (like bash), please try:

export DISPLAY=127.0.0.1:0
ssh -X marko@vm

Or if you're using cmd.exe:

set DISPLAY=127.0.0.1:0
ssh -X marko@vm

Or if you're using powershell.exe:

$env:DISPLAY = '127.0.0.1:0'
ssh -X marko@vm
Improve this answer
6
  • Thank you, this is exactly what I was missing! I will award the bounty as soon as I am allowed.
    – abendigo
    Jun 11, 2015 at 21:01
  • Note that I up-voted roaima's answer (below) because it describes why as well as just giving an answer.
    – Azhrei
    Jun 11, 2015 at 21:59
  • 3
    So roaima's answer explains why the problem occurred, but it did not help me solve the problem. I explained in my question that I was running windows. yaegashi's answer gave me a command to enter on windows that solved my problem. that is why I selected this answer.
    – abendigo
    Jul 7, 2015 at 3:25
  • I registered an account just to up vote this answer. I had searched the internet for long before reaching here.
    – Rio Wing
    Mar 1, 2018 at 21:23
  • 6
    This solution doesn't work for me. set DISPLAY=anything followed by ssh -X user@remote returns CreateProcessW failed error:2 ssh_askpass: posix_spawn: No such file or directory Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).Unsetting the environment variable with set DISPLAY= allows me to ssh successfully again, but without working X forwarding. It doesn't make any sense to me that setting DISPLAY should cause the software to ask for my password this way. github.com/PowerShell/Win32-OpenSSH/issues/1088 github.com/PowerShell/Win32-OpenSSH/issues/1088
    – Pavel Komarov
    Nov 29, 2018 at 22:31
18

When you run ssh -X remotehost and you get DISPLAY=localhost:10 presented to the remote host. ssh listens on that port and forwards traffic back to the calling system, using its original value of DISPLAY to determine the server address.

It's probable that on your local system you've got DISPLAY=:0. Or if you haven't, that's what it's being defaulted as. This instructs the local system to use the UNIX domain socket to communicate with the display. Unfortunately Xming on Windows doesn't set up that UNIX domain socket so your ssh X11 forwarding fails with this sort of error:

$ export DISPLAY=:0
$ ssh -X remotehost xlogo
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0

The fix - at least as far as Xming goes - is fairly simple. Modify the DISPLAY variable to reference a listening TCP socket rather than a UNIX domain socket.

$ export DISPLAY=localhost:0
$ ssh -X remotehost xlogo

You might have to adapt your Xming configuration to listen on the local TCP port 6000. Here is how I start Xming:

Xming.exe :0 -clipboard -multiwindow

And here is evidence to confirm that Xming is listening on port tcp/6000:

$ netstat -na | grep ':6000 .*LISTEN'
  TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING
Improve this answer
5
  • 1
    Thanks, I had this exact problem! I did not know that :0 means the connection is done over a socket. I always thought its just shorthand for localhost:0.
    – Andreas Raster
    Nov 20, 2017 at 14:16
  • I had the same problem with Bash for Ubuntu for Windows & Xming, and this solved it! I just had to set DISPLAY to localhost:0.
    – Ben Richards
    Mar 12, 2018 at 15:01
  • Any idea why DISPLAY=:0 works fine on WSL+XMing for xeyes, but not for ssh -X? Does ssh -X interpret $DISPLAY differently from other local X11 clients? Do other X11 clients fall back automatically to localhost:0 but ssh -X does not?
    – Markus Kuhn
    Sep 28, 2018 at 11:09
  • On man X it says that the empty hostname in DISPLAY=:0 means "The most efficient local transport will be chosen." So may be ssh -X uses a different algorithm to do that compared to say xeyes?
    – Markus Kuhn
    Sep 28, 2018 at 11:16
  • @MarkusKuhn perhaps WSL+Xming is different to Cygwin+Xming. I see that I'm now using DISPLAY=:0 and ssh -X forwards it happily.
    – roaima
    Sep 28, 2018 at 11:40
15

This work for me: Set environment variable in PowerShell:

$env:DISPLAY="127.0.0.1:0"

Then ssh -Y

Improve this answer
0
4

With ssh in Windows10 and Xming, I seem to get "good"(?) results with:

set DISPLAY=localhost:0

and creating an object C:\dev\tty e.g. with

mkdir \dev
echo x > \dev\tty

and using ssh -Y (not ssh -X).

Improve this answer
1
2

Run the following command in Powershell:

setx DISPLAY "localhost:0.0"

Restart powershell afterwards (very important!)

Connect using powershell with ssh -Y username@computer

NOTE: Make sure you ssh using -Y to enable remote graphics

Improve this answer
1
  • 1
    I'd like to explain what makes the setx command the best choice: it works in cmd and in powershell, this command provides the only command-line or programmatic way to directly and permanently set system environment values; but: variables set with setx variables are available in future command windows only, not in the current command window.
    – insaneinvader
    Nov 17, 2021 at 18:28

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.