Ebixio

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 /etc/gdm/gdm.schemas to:

     <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.