why won't x11 display work through ssh login?

Question

I have logged in to a remote server and am trying to display an x application(e.g. firefox). but an error message appears. the below are my attempts to open firefox

Black@Black-PC ~
$ ssh -X kwagjj@$labserver -p 122
[kwagjj@James5 ~]$ firefox
Error: no display specified
[kwagjj@James5 ~]$ exit
logout
Connection to 143.248.146.204 closed.

Black@Black-PC ~
$ ssh -Y kwagjj@$labserver -p 122
[kwagjj@James5 ~]$ firefox
Error: no display specified
[kwagjj@James5 ~]$ 

I used -X, -Y because I read somewhere that these two options are related with credentials regarding X11 and these switches will do the job for me. Even without the -X, -Y switches, my attempt failed.

What does the 'no display speicified' error mean?

P.S. The weird thing is that if I connect to the remote server through my PUTTY and repeat the command 'firefox' it works?!?!(firefox is displayed on local computer)

P.S. my local computer is Windows 7 so I have Xming running on background in order to allow X11 display. As for the attempt written on the upper part, the commands were typed in at Cygwin terminal.

Solution 1

Make sure that you have the DISPLAY-variable set in your cygwin-environment:

export DISPLAY=:0.0

after connecting with SSH, check if that shell also knows the correct DISPLAY-variable with:

echo $DISPLAY

Solution 2

I just ran into this problem connecting to a headless RHEL7 server.

You need the xorg-x11-xauth package installed on your host in order for the DISPLAY variable to get set, and to be properly authorized.

Hope I saved somebody some time.

Solution 3

Thanks to @jensd, @unxnut for helping me. based on your comments I was able to figure out the problem.

The solution needed two steps:

1. the DISPLAY variable should be properly set.
2. when ssh'ing to remote server, the -X switch must be on

my previous attempts lack one or both of these two conditions.

Anyhow, for later users who see this here's are examples to show you what I'm trying to say.

case1

my local machine will have no DISPLAY variable set. And then I will ssh to remote server with -X switch and then try executing xclock.

Black@Black-PC ~
$ echo $DISPLAY

## the blank means that DISPLAY variable has not been specified##
Black@Black-PC ~
$ ssh -X kwagjj@$labserver -p 122
Last login: Tue Jun 24 22:23:13 2014 from 
[kwagjj@James5 ~]$ xclock
Error: Can't open display:
[kwagjj@James5 ~]$ setenv | grep $DISPLAY
DISPLAY: Undefined variable.

as you can see an error Error: Can't open display: is shown at the remote server terminal.

case2

this time, at the local machine, I will specify the DISPLAY variable. But when I'm ssh'ing, I won't turn on the -X switch. The result will be a failure:

Black@Black-PC ~
$ export DISPLAY=:0.0

Black@Black-PC ~
$ echo $DISPLAY
:0.0

Black@Black-PC ~
$ ssh kwagjj@$labserver -p 122
Last login: Tue Jun 24 22:33:32 2014 from 
[kwagjj@James5 ~]$ xclock
Error: Can't open display:
[kwagjj@James5 ~]$ setenv | grep DISPLAY
[kwagjj@James5 ~]$ 

at the start you can see that I have properly set the DISPLAY variable. But even so, after ssh'ing(without the -X switch) the xclock is not executed.

*A different outcome with setenv | grep DISPLAY can be seen here(compare with case1). in case2, the result is just blank. on the other hand, the result of case1 to this command line is DISPLAY: undefined variable.... I'm not sure how this difference is caused but I'm getting a hunch that its related to whether you've satisfied either condition 1. or 2.

case3

this time, I will properly specify the DISPLAY variable at the local machine and also ssh to remote server with my -X switch on.

Black@Black-PC ~
$ echo $DISPLAY
:0.0

Black@Black-PC ~
$ ssh -X kwagjj@$labserver -p 122
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Tue Jun 24 22:37:27 2014 from 
[kwagjj@James5 ~]$ xclock &
[1] 9174
[kwagjj@James5 ~]$ setenv | grep DISPLAY
DISPLAY=localhost:11.0
[kwagjj@James5 ~]$

with this setting, xclock works!! here's a screenshot to prove that I'm not lying. the xclock is successfully shown in my local machine.

Again, check out the result of setenv | grep DISPLAY in this case. It now shows DISPLAY=localhost:11.0. From what I know, this is related with MIT-MAGIC-COOKIE in the .Xauthority file but since I don't know much about this I won't go any further.

Conclusion: from the three cases above, we can confirm that in order for remote X Windows to be displayed properly, both 1. DISPLAY variable of local machine and 2. ssh -X switch must be properly set. Of course, the remote server should allow X11forwarding.

Solution 4

Another case I ran into where ssh will refuse to carry over the DISPLAY variable setting even when you use ssh -X:

$ ssh -X foo
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
...
Add correct host key in /home/jdoe/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/jdoe/.ssh/known_hosts:71
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.

If you are someone who reads the full message that ssh spits back at you, the answer will be immediately obvious to you. However, if you are like me, and don't always read the extremely long messages that display when you ssh into a remote server, because they sysadmin set up an already long MOTD (Message of the Day) or similar warning banner whenever you log into the system, you might easily miss that message!

The fix is, of course (once you have made certain you are actually logging into the system you think you are!!), to edit your "known_hosts" file as suggested by the helpful warning message that you (I) so diligently ignored while logging in. You may run into this situation when you have network or system admins who feel the need to every few months reconfigure the network (job security?).

View more solutions

Comments

[unxnut]

Have you tried to display something locally from your Cygwin terminal? For example, you could find a local X utility such as xclock and run it to see what happens. If you cannot display locally, the remote display won't work. You may also need the X server for Cygwin.

[Ahmed]

Error: Can't open display: :0.0

[trogne]

Do this : export DISPLAY=localhost:0

[Jpsy]

Great answer! The other solutions (setting DISPLAY manually via export) will result in an unencrypted transmission between client and server! On Debian Squeeze it was the package "xauth" that needed to be installed to get everything working. After a re-login per ssh -X an echo $DISPLAY returned a URL+port and a call of xterm & opened a terminal in a local window.

[Maxim Suslov]

case 0: to have running local X server. For Windows, it could be Xming, Cygwin X, and vcXsrv.

[Miron Veryanskiy]

sudo apt install xauth on ubuntu & debian