11

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?

Dave Jarvis
  • 957
  • 2
  • 11
  • 24
Fabian
  • 111
  • 1
  • 1
  • 4
  • 1
    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 sorry, I didn't see your comment. Yes, I can open xterm on my local machine – Fabian Sep 16 '11 at 18:28

7 Answers7

9

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.

Gilles 'SO- stop being evil'
  • 59,745
  • 16
  • 131
  • 158
  • 1
    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 'SO- stop being evil' 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 'SO- stop being evil' 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 08 '17 at 02:55
  • @DanDascalescu If you run `DISPLAY=:0 xterm` then this question doesn't apply to you. This question is about running a program on the server and having it display on the client. If you want the server's display then see https://unix.stackexchange.com/questions/10121/open-a-window-on-a-remote-x-display-why-cannot-open-display/10126#10126 – Gilles 'SO- stop being evil' Aug 08 '17 at 10:56
3

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
ed.
  • 254
  • 1
  • 5
3

As well as X11Forwarding yes, I also needed to add

X11UseLocalhost no

in /etc/ssh/sshd_config

as described here.

Zanna
  • 69,223
  • 56
  • 216
  • 327
user2400538
  • 31
  • 1
2

Access control of X is probably in the way.

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

VedVals
  • 3,391
  • 9
  • 30
  • 46
Geert
  • 21
  • 1
  • After which everyone can see which keys you type on your keyboard (and snoop your root password, bankaccounts, PGP pass phrase and all what not). – Carlo Wood Jun 10 '20 at 02:38
1

I found that xauth had not been installed.

allen
  • 11
  • 1
0

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/

Paul Maunders
  • 1
  • 1
-1

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

lazyPower
  • 5,321
  • 2
  • 32
  • 40
animaletdesequia
  • 8,306
  • 4
  • 26
  • 43
  • 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. – nanofarad 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