Open a window on a remote X display (why "Cannot open display")?
(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 theDISPLAY
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 cookie123456
”. The X authority file is normally indicated in theXAUTHORITY
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 ifDISPLAY
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
andXAUTHORITY
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
andXAUTHORITY
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.
I solved this issue 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.
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"