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?

  • 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. – belacqua 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

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.

  • 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
  • I'm running DISPLAY=:0 xterm and still get the xterm: Xt error: Can't open display: :0 error, so the environment variable is not the problem. – Dan Dascalescu Aug 8 '17 at 2:55

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
  • 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
  • My DISPLAY variable is localhost:10.0 – Alexis Wilke May 17 '16 at 23:00

Access control of X is probably in the way.

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

As well as X11Forwarding yes, I also needed to add

X11UseLocalhost no

in /etc/ssh/sshd_config

as described here.

I found that xauth had not been installed.

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/

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

  • 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. – belacqua Sep 16 '11 at 17:51
  • I think a VNC connection is necessary. – hexafraction Aug 16 '12 at 14:46
  • @enzotib, well... actually ssh is first connecting, then xterm is started in that ssh environment. So either way it is pretty much the same thing only if you use ssh -X remote first then you can check whether you check with echo $DISPLAY to make sure that $DISPLAY is properly set on the remote computer after an ssh -X. – Alexis Wilke May 17 '16 at 23:09

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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