94

Once upon a time,

DISPLAY=:0.0 totem /path/to/movie.avi

after ssh 'ing into my desktop from my laptop would cause totem to play movie.avi on my desktop.

Now it gives the error:

No protocol specified
Cannot open display:

I reinstalled Debian squeeze when it went stable on both computers, and I guess I broke the config.

I've googled on this, and cannot for the life of me figure out what I'm supposed to be doing.

(VLC has an HTTP interface that works, but it isn't as convenient as ssh.)

The same problem arises when I try to run this from a cron job.

Gilles 'SO- stop being evil'
  • 829,060
justin cress
  • 1,331
  • 1
    Does your remote machine show a .Xauthority file? The other obvious question is - are your ssh server and client configured to allow X forwarding? What command did you use to ssh? – Faheem Mitha Mar 25 '11 at 21:35
  • 1
    am I trying to forward X? I want the command to be executed on the host, not the client. My ssh command is just ssh me@host locate .Xauthority on the host computer doesnt match any files. – justin cress Mar 25 '11 at 21:42
  • As Faheem suggests, there's a good change that your problem is due to totem not finding your X cookie, and you need to set XAUTHORITY to the proper value, i.e., the value in your regular session on your desktop. Read Linux: wmctrl cannot open display when session initiated via ssh+screen for some background; also see the related answer As root can I launch a graphical program on another users desktop?. – Gilles 'SO- stop being evil' Mar 25 '11 at 21:49
  • @justin: yes, the command is executed on your desktop, but does the totem window appear on your laptop? If so, that is X fowarding. If you are doing that, I wonder how you are handing the sound. And why are you setting DISPLAY manually? That is not usually done. The Xauthority file would be located at ~/.Xauthority on any machine. – Faheem Mitha Mar 25 '11 at 21:51
  • @Gilles: Afaik it is not necessary to set .Xauthority manually. The whole process should be completely automatic. The first thing I would do is check your ssh server and client are configured properly for X forwarding. Second, check there is a ~/.Xauthority, and if not check your desktop has the necessary X programs installed to generate it. – Faheem Mitha Mar 25 '11 at 21:55
  • @gilles 'but does the totem window appear on your laptop?' no, i'm basically using my laptop as a remote control – justin cress Mar 25 '11 at 21:56
  • OTOH, if you are trying to actually bring up totem on your desktop, the above does not apply, though I'd have to ask why you are doing it that way. – Faheem Mitha Mar 25 '11 at 21:57
  • @justin: wrong attribution. :-) Ok, then ignore what I said above. I'm not familiar with that use case. And what Gilles said is probably the way to go. – Faheem Mitha Mar 25 '11 at 21:58
  • @Faheem: There's nothing to do with ~/.Xauthority if it exists. But if the XAUTHORITY environment variable is set (pointing to a different file) in the desktop session, justin must set it to the same value in the ssh session. Oh, and the reason justin is setting DISPLAY=:0 is precisely so that totem will display on the desktop rather than through the forwarded X connection. The sound will be on the desktop as well unless there's some automatic sound forwarding (unlikely). – Gilles 'SO- stop being evil' Mar 25 '11 at 21:59
  • @Gilles: Right. I think you've got it figured out. Sorry for the noise. – Faheem Mitha Mar 25 '11 at 22:00
  • @Gilles what to do if .Xauthority doesnt exist, xauth is installed... – justin cress Mar 25 '11 at 22:11
  • 1
    alright, physically sitting at the computer and typing echo $XAUTHORITY gives /var/run/gdm3/auth-for-jcress-bb32gX/database in the ssh session, typing echo $DISPLAY = (the path above) does not resolve the problem – justin cress Mar 25 '11 at 22:20
  • 2
    I blame GDM3, why couldn't they have just kept $XAUTHORITY at ~/.Xauthority like everybody expects it to be. – Arrowmaster Mar 25 '11 at 22:24

3 Answers3

96

(Adapted from Linux: wmctrl cannot open display when session initiated via ssh+screen)

DISPLAY and AUTHORITY

An X program needs two pieces of information in order to connect to an X display.

  • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.

  • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.

You're trying to act on the windows that are displayed on your desktop. If you're the only person using your desktop machine, it's very likely that the display name is :0. Finding the location of the X authority file is harder, because with gdm as set up under Debian squeeze or Ubuntu 10.04, it's in a file with a randomly generated name. (You had no problem before because earlier versions of gdm used the default setting, i.e. cookies stored in ~/.Xauthority.)

Getting the values of the variables

Here are a few ways to obtain the values of DISPLAY and XAUTHORITY:

  • You can systematically start a screen session from your desktop, perhaps automatically in your login scripts (from ~/.profile; but do it only if logging in under X: test if DISPLAY is set to a value beginning with : (that should cover all the cases you're likely to encounter)). In ~/.profile:

    case $DISPLAY in
  :*) screen -S local -d -m;;
esac

    Then, in the ssh session:

    screen -d -r local

  • You could also save the values of DISPLAY and XAUTHORITY in a file and recall the values. In ~/.profile:

    case $DISPLAY in
  :*) export | grep -E '(^| )(DISPLAY|XAUTHORITY)=' >~/.local-display-setup.sh;;
esac

    In the ssh session:

    . ~/.local-display-setup.sh
screen

  • You could detect the values of DISPLAY and XAUTHORITY from a running process. This is harder to automate. You have to figure out the PID of a process that's connected to the display you want to work on, then get the environment variables from /proc/$pid/environ (eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=')¹).

Copying the cookies

Another approach (following a suggestion by Arrowmaster) is to not try to obtain the value of $XAUTHORITY in the ssh session, but instead to make the X session copy its cookies into ~/.Xauthority. Since the cookies are generated each time you log in, it's not a problem if you keep stale values in ~/.Xauthority.

There can be a security issue if your home directory is accessible over NFS or other network file system that allows remote administrators to view its contents. They'd still need to connect to your machine somehow, unless you've enabled X TCP connections (Debian has them off by default). So for most people, this either does not apply (no NFS) or is not a problem (no X TCP connections).

To copy cookies when you log into your desktop X session, add the following lines to ~/.xprofile or ~/.profile (or some other script that is read when you log in):

case $DISPLAY:$XAUTHORITY in
  :*:?*)
    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

¹ In principle this lacks proper quoting, but in this specific instance $DISPLAY and $XAUTHORITY won't contain any shell metacharacter.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • 2
    One way to automate this would be to create a ~/.xprofile which should only be run during the the X login and have it create/update ~/.Xauthority with the correct info. Would a symbolic link be enough? – Arrowmaster Mar 25 '11 at 23:16
  • @Arrowmaster: That's a good suggestion. I hadn't thought of it. It won't work in all cases, for example if you log into more than one X session (on different terminals, with vnc, …), but it's simple, and it's good enough for typical use. A symbolic link is the best way. Hmm, actually there's a better, simple way: you can copy the information into ~/.Xauthority. – Gilles 'SO- stop being evil' Mar 25 '11 at 23:21
  • 1
    Would putting something like xauth extract - $DISPLAY | xauth -f "$HOME/.Xauthority" merge - in ~/.xprofile solve the case of multiple $DISPLAY's? – Arrowmaster Mar 25 '11 at 23:52
  • @Arrowmaster: What problem do you see with multiple displays? While your code may be a little cleaner in principle since you're only extracting information about the display you're interested in, I don't see anything wrong with a simple merge in the asker's case, or indeed outside very unusual circumstances. – Gilles 'SO- stop being evil' Mar 25 '11 at 23:58
  • I came up with that before I noticed your edit. I based it mostly on the xauth man page example for merging across hosts with ssh. In this case I'm guessing the $XAUTHORITY created by GDM3 will only contain a single entry so your method with a single xauth call seem simpler. – Arrowmaster Mar 26 '11 at 00:07
  • 2
    Reading the environment out of an existing process connected to the display is unexpected as to be delightfully evil. I approve wholeheartedly. Unix.SE needs an Evil Genius™ badge for this. – derobert Nov 30 '11 at 07:22
  • In my case I export this too: export XAUTHLOCALHOSTNAME=localhost – botzko Nov 09 '12 at 08:04
  • At least on debian, it's fairly easy to deduce which file from /var/run/gdm3 is correct, since it will contain the username of the person you want to open the window for. – Thomas Dignan Dec 23 '14 at 03:50
  • (...) make the X session copy its cookies into ~/.Xauthority This basically reverts the move done by distribution(s) from this file to one with random name and I guess there is a reason this move has been made… – Piotr Dobrogost Jul 25 '17 at 11:39
  • 1
    @PiotrDobrogost AFAIK this isn't a “move by distributions”, it's a quirk of gdm. At least on Debian and Ubuntu, the others (xdm, slim, lightdm, kdm) populate ~/.Xauthority in the traditional way. I suspect that the reason gdm doesn't do it is that they didn't bother to program it (the original cookie is created to display the login screen, so at this point it can't be in the user's home directory, it has to be copied there when the user has logged in). – Gilles 'SO- stop being evil' Jul 26 '17 at 15:49
  • (…) it's a quirk of gdm. Is it? I'm on KDE spin of Fedora which uses sddm as display manager and XAUTHORITY is /tmp/xauth-1000-_0. This suggests that there is global change in policy with regard to location of X authority file… – Piotr Dobrogost Jul 26 '17 at 17:00
  • @PiotrDobrogost Once again, why do you think it's a quirk of policy, rather than an implementation defect? Has Fedora changed the behavior of sddm? – Gilles 'SO- stop being evil' Jul 27 '17 at 07:53
  • @Gilles, Thanks for the explanation. When I do "echo $DISPLAY" on my VM installed on my laptop, it reads "localhost:10.0". Wondering what the ".0" in "localhost:10.0" means? – alpha_989 Nov 07 '17 at 17:28
  • The reason I am asking is because I cant repeatably get the Xdisplay to appear on my tmux session, so trying to understand what the DISPLAY parameter stands for. At certain times, I can start tmux and do "DISPLAY=:10", and xeyes will display on my local machine, sometimes its "DISPLAY=:0" which will display xeyes on my local machine and now it seems when I can get xeyes on my local machine, DISPLAY is set to "localhost:10.0". – alpha_989 Nov 07 '17 at 17:31
  • @alpha_989 The .0 is a screen number. What's a screen in this context? Nothing to do with GNU screen, it's basically one of several monitors attached to the same display, but using a very old mechanism that doesn't allow windows to move from one screen to the other. Nowadays all the monitors are treated as a single unit for the purpose of telling an application where to put its window. :10 is an abbreviation for :10.0, and omitting the .0 shouldn't cause any problem. – Gilles 'SO- stop being evil' Nov 07 '17 at 20:34
  • @alpha_989 When you start tmux, it picks up DISPLAY from the environment. When you open a window, this environment variable is transmitted to the process (usually a shell) that is running in that window. Tmux has a mechanism to change its own value of DISPLAY when you attach it from somewhere else, but that only applies to new windows. Inside a particular shell in a window, $DISPLAY reflects the location where you opened the window. – Gilles 'SO- stop being evil' Nov 07 '17 at 20:37
25

Solved by adding:

xhost +si:localuser:$USER

to ~/.xprofile. I don't know if this is altogether secure (I'd be very interested to hear what more knowledgeable folk think), but I'm guessing that it's a lot better than turning off access control (with xhost +) as is commonly suggested when you google for this issue.

Z0OM
  • 3,149
edam
  • 351
  • 1
    localuser server-interpreted addresses are completely secure. Debian even does this by default as part of the login process (in /etc/X11/Xsession.d/35x11-common_xhost-local). See the Xsecurity man page for more details. – Sam Morris May 31 '13 at 22:31
  • If you're on a LAN, xhost + is probably enough in most cases... – Alexis Wilke May 17 '16 at 22:39
  • Would you be able to explain what this command means? – alpha_989 Nov 07 '17 at 16:33
  • 1
    @alpha_989: It means "Grant access [+] to any locally-running [localuser] application which is running as me [$USER]." The "si" is just glue (see xhost(1) and Xsecurity(7) for docs). By itself, this command does not allow any kind of remote access or X11 forwarding (for which the "magic cookie" mechanism is usually preferred over xhost). – Kevin Aug 20 '19 at 22:10
  • I believe this is more secure than using xauth because the Xauthority file might be stored on a network filesystem which can be read by an admin. Of course, many OSes (like Debian) deny remote X connections by default, so Xauthority over NFS isn't necessarily exploitable. – hackerb9 Jun 07 '23 at 00:24
4

Works for me, debian wheezy -> ubuntu trusty.

Note: in this case the server is not running a display-manager, it's a 'headless' virtual machine with no graphics card or monitor attached.

bob@laptop:~$ grep -iB 1 tcp /etc/gdm3/daemon.conf
[security]
DisallowTCP = false
bob@laptop:~$ ssh -C -R 6000:127.0.0.1:6000 alice@server
X11 forwarding request failed on channel 0
alice@server:~$ export DISPLAY=:0.0
alice@server:~$ xterm

X display on laptop shows output of xterm running on server.

Debug using:

bob@laptop:~/tmp$ nc -v 127.0.0.1 6001
localhost [127.0.0.1] 6001 (x11-1) : Connection refused
bob@laptop:~/tmp$ nc -v 127.0.0.1 6000
localhost [127.0.0.1] 6000 (x11) open
alice@server:~$ nc -v 127.0.0.1 6000
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded!*
alice@server:~$ strace xterm

strace will spill loads of gory details about what it's doing, you should be able to guess where it gets stuck - waiting for a connection or whatever.

In one line ..

ssh -C -R 6000:127.0.0.1:6000 alice@server "DISPLAY=:0.0 xterm"
HalosGhost
  • 4,790
jmullee
  • 631