25

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
0

5 Answers 5

28
+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
2
  • 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 Commented Nov 29, 2018 at 22:31
  • You probably found out already, but there's a workaround for this by creating an empty file with the path C:\dev\tty. The dev who fixed the bug wrote an explanation for it: github.com/PowerShell/Win32-OpenSSH/issues/…
    – clausavram
    Commented Dec 18, 2020 at 21:26
20

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
3
  • 1
    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? Commented Sep 28, 2018 at 11:09
  • 2
    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? Commented 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. Commented 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

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).

1
3

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

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. Commented Nov 17, 2021 at 18:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .