Home > Uncategorized > X11 remote display

X11 remote display

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:


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.

Categories: Uncategorized Tags: ,
  1. No comments yet.
  1. No trackbacks yet.