[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cannot open display: localhost:0.0

On 9/23/18 4:00 PM, Gene Heskett wrote:
> On Sunday 23 September 2018 06:30:01 Étienne Mollier wrote:
> > Maybe try:
> >
> > 	xhost +LOCAL:
> > 	DISPLAY=localhost:0.0 xterm
> On which machine? The target of the ssh login, or this one
> with the comfy office chair to sit it?

That is not clear out of the context indeed.  In that very
situation, there is no remote host considered yet.  The purpose
was to demonstrate local graphical connection through the TCP
stack, instead of Unix sockets like it is usually done by X
nowadays.  Except it that the graphical server is seemingly
reluctant to work in this configuration.

Let's clarify a bit.  By convention, “local” will be the
terminal on your desk, and “remote”, the target of the SSH
login.  Their use in commands should be replaced by machines' IP
addresses; or name definition in “/etc/hosts” if applicable.

To run remote X application through TCP connections, one had
firstly to ensure the X server was listening to TCP connections;
of course this check was never done, as long as it was a default
behavior.  Debian, and most today's distributions, ship by
default with X servers that don't listen to TCP, so that is not
obvious to establish TCP listening.  It is highly dependent on
the way X is started (through GDM3, KDM, SDDM, LightDM, startx,
or whatever).  For instance, by using startx, I have in my

	exec /usr/bin/X -nolisten tcp "$@"

As you can see, the option to not listen to TCP connections is
clearly specified.  When I happen to need a listening X server,
I don't tamper with my main display, and use another X server
instead, like “Xephyr”, that I launch on display “:1” for

Secondly, the current session had to be configured to authorize
X client from “remote” host:

	local$ xhost +remote

I believe there are ways to do some basic per-user authorization
as well, this is documented in the manual of xhost(1).  Far too
often, I saw the easy solution consisting in allowing every one
on the network to tamper with one's X server (big transparent
window in foreground to annoy the neighbour, anyone?), but it
sure does the job:

	local$ xhost +  # Don't do that!

Last point was to setup properly the environment on the remote
host at the beginning of the session, through the setting of
DISPLAY variable in the environment.  Assuming the X server,
started on the local host, opened its display on :1, the setting
should be:

	remote$ DISPLAY=local:1
	remote$ export DISPLAY
	remote$ xterm

You can check the display on your local machine by doing, on a
newly opened shell window:

	local$ echo "$DISPLAY"

/Theoretically/, X programs should start properly, and appear on
the screen of the “local” machine.  Wayland has been mentioned,
so that may not even work well on desktop environment running on
top of Wayland instead of X11.

X11 forwarding functions differently, as instead of using a
dedicated TCP connection to the X server on the local machine,
the X client running on the remote machine babbles through an
SSH connection instead.  That is why it works, even if X doesn't
listen to TCP 6000.

Kind Regards,
Étienne Mollier <etienne.mollier@mailoo.org>

Reply to: