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 “/etc/X11/xinit/xserverrc”: #!/bin/sh 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 instance. 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" :1 /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.moll...@mailoo.org>