Assuming that you have two hosts:
- hostA has the display you want to use
- hostB has the application you want to run
First, you log in to hostA and run
xhost +hostB on it to allow hostA's display to be accessed by hostB. Then, you log into hostB, run
DISPLAY=hostA:0 ; export DISPLAY on it, and start your application.
Also note: these are old-style completely unencrypted X11 connections, which are usually disabled by default on modern Linux distributions. If you want to use these commands, you may first have to do something on hostA to configure its X11 server to listen for incoming connections over the TCP protocol, and not just over local UNIX sockets.
(For a long time, this was done by adding a
-nolisten TCP option to the X server command line, and you would need to remove this option to use unencrypted X11 connections. Modern Xorg X servers may flip the sense of these options: you might need to add an explicit
-listen TCP option to enable non-local unencrypted X11 connections.)
On a Linux/Unix system,
DISPLAY=:0.0 refers to a X11 display that is accessible using UNIX socket
/tmp/.X11-unix/X0, so it is the first (and usually only) local X11 server. On a Windows system, this mechanism does not exist.
The UNIX socket mechanism is used only when it is available on the local system architecture and the hostname part of the DISPLAY variable is an empty string. If a hostname is listed, even if it is "localhost", a TCP connection is used.
If a TCP connection is used,
DISPLAY=hostname:X.Y refers to a X11 server listening on
hostname in TCP port (X+6000).
When you start a Windows-based X11 server - perhaps a commercial one like Reflection X, or a free one like VcXsrv or the classic Xming, it will by default start listening on TCP port 6000 as soon as it is started. Modern versions may default to listening on
localhost only for security; the classic alternative is listening on all IP addresses the system has.
The modern, secure way of using X11 is SSH-based X11 forwarding. When you start a SSH client with X11 forwarding enabled, it will connect to the local X11 server on the SSH client host using whatever mechanism available. It will pass on this connection to whatever host you connect to using a secure subchannel in the SSH connection.
sshd daemon on the remote host will start listening on a free TCP port (usually in the 6010+ range), sets up a
DISPLAY=localhost:X.0 (where X = chosen port number - 6000), and also cooperates with the SSH client to automatically set up
xauth cookies for you, if required by the X11 server at the SSH client side.
As far as the X11 server on the client host is concerned, the incoming X11 traffic comes from the local SSH client process, so
xhost command is normally not needed on the SSH client host.
The result: you don't need to set
DISPLAY manually, nor the
xhost command at all. Just make sure your local X11 server is running, enable X11 forwarding in your SSH client, connect to the remote host with SSH and start any X11 GUI program. The windows of that program will just pop up on your local display. It just works.
This can be something of a revelation to someone that is used to the classic style of setting up X11 connections.
More than 15 years ago, I showed this to a grumpy old database administrator, who occasionally had needed to go to the server room to install Oracle as firewalls did not allow the classic un-encrypted X11 connections.
He hugged me.