Ubuntu Windows10 App -- X11 Forwarding -- $DISPLAY Error

ubuntu ssh x11 sshd display

25,750

Solution 1

I was seeing the message debug1: X11 forwarding requested but DISPLAY not set because I was not setting the DISPLAY environment variable in the shell before connecting to the host. I am using 'Bash on Windows' with openssh.

Here is what needs to be done:

samik@mysystem:~$ export DISPLAY=localhost:0.0
samik@mysystem:~$ ssh -X samik@remotehost

Solution 2

If you are running Ubuntu in the "Windows subsystem for Linux", you need to run some X server before you can forward any X client connections on your RaspPi to it. The Ubuntu system you have installed very likely won't do that out of the box.

So you need to install an X server. Popular choices are Xming, Cygwin X, or vcXsrv, others will work as well.

There are many tutorials for that on the web, for example here.

25,750

Author by

Hanslaught

Updated on September 18, 2022

Comments

Hanslaught over 1 year

I've been searching StackExchange and elsewhere for awhile now. None of the fixes seem to work for me (or only fix a part of the issue).

I am trying to get into my Raspberry Pi 3, which is running Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv71. I am attempting to use it as the server and my Windows 10 Pro desktop as the client (through the Ubuntu Windows 10 terminal app). Doing it through PuTTY, with X11 Forwarding enabled, works fine. However, doing it through the Ubuntu app with ssh -X -v user@server and then testing it with xlogo just comes up with Error: Can't open display:.

I find this in the debugging for X11 Forwarding through ssh after logging in: debug1: X11 forwarding requested but DISPLAY not set. When I run echo $DISPLAY while logged in, I get a blank line as a result.

I have set the following options on the server's /etc/ssh/sshd_config file:

Port 22
Address Family inet
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

The command sudo service ssh status results in a bunch of lines indicating that the OpenBSD Secure Shell Server is active (running).

On my client, there is the following lines only (all written in by me) in the file ~/.ssh/config:

Forward X11 yes
ForwardAgent yes

I have also tried the command, ssh -Y -v user@server, to no avail (X11 Forwarding DISPLAY issue still).

Also, I have tried editing the /etc/default/ssh file in my server to add -4 to the options passed to sshd. The file now has these lines:

# Options to pass to sshd

SSHD_OPTS=-4

Note that I've tried xlogo on my client directly and it results in the same error, though if I try it on my server directly it works just fine. Also, to get the PuTTY method to work I use XMing and run it while PuTTY is going.

I have tried export DISPLAY=:10.0 on the server and then restarting ssh server and rebooting and re-logging in with ssh, but it doesn't change anything. Trying this command on the client and re-logging in, etc, results in a new error (debug1: failure x11 and after xlogo, Error: Can't open display: server:10.0 where "server" is my name in my user@server login).

I am not very knowledgeable on the topic, so if there is something dumb I am doing or not saying, let me know. Thanks.

Edit: output from -vvv due to Kenster asking for it. Not sure if there's a good way of formatting this. New to this site!

myname@myname-PC:~$ ssh -vvv -X user@server
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/myname/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "raspberrypi" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to raspberrypi [192.168.1.124] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u2
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to raspberrypi:22 as 'pi'
debug3: hostkeys_foreach: reading file "/home/myname/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/myname/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from raspberrypi
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:SwUQGmGCYHVAinSJ2TmUxr5lN6Hutu70nZEhrIJ36iQ
debug3: hostkeys_foreach: reading file "/home/myname/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/myname/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from raspberrypi
debug3: hostkeys_foreach: reading file "/home/myname/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/myname/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 192.168.1.124
debug1: Host 'raspberrypi' is known and matches the ECDSA host key.
debug1: Found key in /home/myname/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/myname/.ssh/id_rsa ((nil))
debug2: key: /home/myname/.ssh/id_dsa ((nil))
debug2: key: /home/myname/.ssh/id_ecdsa ((nil))
debug2: key: /home/myname/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/myname/.ssh/id_rsa
debug3: no such identity: /home/myname/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/myname/.ssh/id_dsa
debug3: no such identity: /home/myname/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/myname/.ssh/id_ecdsa
debug3: no such identity: /home/myname/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/myname/.ssh/id_ed25519
debug3: no such identity: /home/myname/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user@server's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to raspberrypi ([192.168.1.124]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug1: X11 forwarding requested but DISPLAY not set
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env USER
debug3: Ignored env NAME
debug3: Ignored env LS_COLORS
debug3: Ignored env HOSTTYPE
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env LESSOPEN
debug3: Ignored env LESSCLOSE
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Mar  1 23:14:26 2018 from 192.168.1.8
user@server:~ $ debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug3: send packet: type 98
user@server:~ $ xterm &
[1] 5043
user@server:~ $ xterm: Xt error: Can't open display:
xterm: DISPLAY is not set
^C
[1]+  Exit 1                  xterm
user@server:~ $

Admin about 6 years

Could you run ssh with the -vvv option to connect to the pi and edit your question to include the verbose output? It would be helpful to see the exact ssh command that you're running and whether it actually requests X forwarding.
Admin about 6 years

Isn't :10.0 the eleventh display? Did you mean export DISPLAY=:0?
Admin about 6 years

Not being able to run xlogo on the Ubuntu machine (client) possibly means that you are not running an X server, but Wayland. You need to have an X server running to be able to forward X. Open a terminal on the Ubuntu machine, and do echo $DISPLAY to see if it is set at all.
Admin about 6 years

@dessert Just tried export DISPLAY=:0 and export DISPLAY=:10.0 and both resulted in debug1: failure x11 debug3: send packet: type 92 at the end of the ssh -vvv -X user@server thing after entering password and hitting enter. I think I tried 0 before but it wasn't working either.
Admin about 6 years

Go to /tmp/ and delete the .X*-lock files, then reboot the server. Then check which DISPLAY is set for X with the who command.
Admin about 6 years

@Mioriin Deleted a file looking similar to that. Then did user@server:~ $ who $DISPLAY user tty1 2018-03-05 20:48 user tty7 2018-03-05 20:48 (:0) user pts/0 2018-03-05 20:50 (192.168.1.8) So it appears that, since my client has the IP Address of 192.168.1.8, its DISPLAY is set. However, I don't know if this is the right interpretation.

Hanslaught about 6 years

I have Xming already and run it while I attempt to use X11 Forwarding. I do use that Ubuntu. However, I will take a look at those links; I could be missing something.
Hanslaught about 6 years

I am not sure it's actually running Ubuntu the way I'm using it. It is just an Ubuntu terminal. But I don't know how that works.
Timo over 3 years

The Cygwin link should be removed, it will probably not further considered by MS due WSL (2).
Timo over 3 years

Is this enough instead of installing an x-server: export DISPLAY=localhost:0.0;ssh -X samik@remotehost. Can I start an x-app as root on the server?
thoni56 almost 3 years

I wish I could upvote more than once... So obvious, but for Windows, it's easy to miss because you normally wouldn't have that set. Until you want to do exactly this.
thoni56 almost 3 years

And of course on Windows you can't do export ... (unless you are on WSL, Cygwin, Msys or Git Bash...) you need to set DISPLAY localhost:0.0 or even setx DISPLAY localhost:0.0 (according to docs.microsoft.com/en-us/windows-server/administration/…) to set it more permanently from a command prompt.
thoni56 almost 3 years

@timo, Cygwin is still relevant, since it has a different purpose than WSL. (But for running actual Linux on a Windows box WSL is a better choice today.) And yes what you wrote works, but it is actually two commands. Presumably you asked if setting the DISPLAY for just the single ssh command is sufficient. Again, yes, DISPLAY=localhost:0.0 ssh -X <user>@<host> totally works as a one-off command.
Chris almost 3 years

setx DISPLAY localhost:0.0 was indeed key for my issue. Must also restart the terminal (Windows Terminal in my case) to pick up the new environment variable before trying to connect. You might then get a message about a lack of trust untrusted X11 forwarding setup failed when using ssh -X. For now, I'm working around that using ssh -Y, as I'm not sure why it's untrusted....In my case this is not Ubuntu or WSL, it's actually Raspberry OS Lite running on a Pi 4.