There’s no shortage of tutorials on how to use X11’s remote display facilities. On modern, properly configured systems, all you need to do is to use the -X or -Y option to ssh, and the magic is all taken care of by ssh and xauth. Unfortunately, sometimes servers are mis-configured and this simple solution doesn’t work.
On one server I was trying to use, sshd was compiled with a hard-coded path for xauth that was incorrect. This is easy to see when adding the “-v” switch to ssh. Look for:
debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing.
With no admin rights on the server, the normal work-around is to use the XAuthLocation option on the client side, either in the ~/.ssh/config file, or on the command line:
ssh -o XAuthLocation=/proper/path. Some versions of sshd (including the one I was using) ignore this option.
Since I was working in a fairly secure environment, I decided to skip ssh/xauth part, and just set the DISPLAY environment variable on the server to “DISPLAY=my.client.ip:0.0”. That’s all nice and dandy, but my Ubuntu client was using Unix domain sockets instead of TCP for X11 so there was no way to connect to it remotely. First I tried modifying
/etc/X11/xinit/xserverrc on the client to remove the “-nolisten tcp” option. That didn’t seem to do the trick (there was nobody listening on port 6000 after I restarted X). It turns out gdm has a different configuration file that also needs to be modified. I then changed
<schema> <key>security/DisallowTCP</key> <signature>b</signature> <default>false</default> </schema>
After X was restarted, I had X11 listening on port 6000. All that was left to do was to allow the server to connect (
xhost +server.name.com) and everything was working like a charm.
Before you open up X11 to remote TCP connections as shown above, make sure you read up on it and understand the security implications.