Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm trying to open xterm on my remote server (Ubuntu Server 10.04) with ssh:

ssh -X name@machine xterm

but the error returned is:

xterm Xt error: Can't open display: :0.0`

I googled and tried everything I found. Still getting this error. The DISPLAY-variable should be set automatically, right?

Part of sshd_config:

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

Any advice?

share|improve this question
    
Can you run xterm in the current terminal before ssh-ing? –  enzotib Sep 16 '11 at 15:56
    
@belacqua: it is not required. I usually connect to a remote headless server and could easily run remote X applications on the local X server. –  enzotib Sep 16 '11 at 18:09
    
@enzotib -- thanks ; I didn't know that. –  belacq Sep 16 '11 at 18:23
    
@enzotib sorry, I didn't see your comment. Yes, I can open xterm on my local machine –  Fabian Sep 16 '11 at 18:28

6 Answers 6

If ssh is able to establish the connection, it will set DISPLAY to the proper value. Since you have X11DisplayOffset set to 10 (the default value), ssh will use the first available display starting at 10. If you see a value that's lower than 10¹, then something is interfering with the normal X11 forwarding set up by ssh, at least by overriding DISPLAY. The value :0 (or :0.0, the part after the dot is irrelevant) indicates the first display that was started on the machine, which in typical cases is the active session (or the graphical login prompt) on the machine's console.

The most likely explanation for the behavior you observe is that one of your shell configuration files sets DISPLAY. The most obvious culprit is ~/.bashrc (which due to a quirk of bash is executed whenever the parent of bash is rshd or sshd, even if the shell is not interactive). Another file that defines environment variables is /etc/environment. If that's the case, the solution is obvious: don't set DISPLAY there. (There are very few cases where you need to set DISPLAY manually.)

There are other exotic explanations. This might happen if you've changed your login shell to screen (a cute idea in theory, but not practical) and you have a shell initialization file that forcibly sets DISPLAY inside screen (not such a good idea). This could also happen if you configured the server to accept environment variables sent by the client (AcceptEnv directive in sshd_config), the client is sending DISPLAY, and the X connection couldn't be established. Or it could happen if you set an environment variable on the server via the command directive in ~/.ssh/authorized_keys. Or xterm could be a script.

¹ Or whatever the value of X11DisplayOffset is in the server configuration, but it's hardly ever changed from the default.

share|improve this answer
    
having ways listed to fix the various problems you mention would be helpful. –  George Stocker Jan 24 '13 at 21:15
    
@GeorgeStocker All of these problems are of the form “there's some setting in a configuration file”, so the fix for all of these is to remove or change the setting. Is there one in particular that you can identify but not fix? –  Gilles Jan 24 '13 at 21:18
    
I see DISPLAY=localhost:11.0 in my env, but its relevance and whether I should change it to DISPLAY 10.0 is unclear. –  George Stocker Jan 24 '13 at 21:25
    
@GeorgeStocker Then your symptoms don't match this question. I've updated my answer to clarify that 10 is the cutoff value below which this answer applies. 11 is an expected value here (probably the second active SSH connection with X forwarding). –  Gilles Jan 24 '13 at 21:31

Your command should work, or at least it does for me. Try this instead:

ssh -Y user@machine xterm

Edit (1):

Try this:

ssh -X user@machine env

That should show all the environment. There should be various SSH things in there, and also DISPLAY. DISPLAY should be 10.0.

You could also try this:

ssh -X user@machine DISPLAY=10.0 xterm
share|improve this answer
    
I tried it with -Y but it didn't work either. I still get Can't open display: :0.0 –  Fabian Sep 16 '11 at 16:03
    
What's your local machine running? The :0.0 is concerning, since it's the default for a local X server, not a remote one... –  ed. Sep 16 '11 at 18:30
    
I use Ubuntu 10.04, Linux Mint 11 or Mac OS X 10.7. Usage depends on location (work/home), but the error is all the same –  Fabian Sep 16 '11 at 18:38
    
I'll edit the answer... (1) –  ed. Sep 16 '11 at 20:45

Access control of X is probably in the way.

Run xhost + (from package x11-xserver-utils) to completely disable access control.

share|improve this answer

Also, check that you have X11 installed on the client end. I was getting this issue when I upgraded my Mac to OS X Mountain Lion. Mountain Lion removes X11, so you have to install it again via the open source X Quartz project. http://xquartz.macosforge.org/landing/

share|improve this answer

I found that xauth had not been installed.

share|improve this answer

You should open first the connection,and once established open xterm.

share|improve this answer
    
Thank you for your answer. What do you mean with "open a connection"? When I use ssh -X name@machine and after the connection xterm I get the same error. Did you mean that? ;) –  Fabian Sep 16 '11 at 14:42
    
No, it should work also without connecting first. –  enzotib Sep 16 '11 at 15:53
    
@Fabian -- I believe that is what he meant. –  belacq Sep 16 '11 at 17:51
    
I think a VNC connection is necessary. –  hexafraction Aug 16 '12 at 14:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.