Linux remote access using X11


The X11 Window System is the component that provides Linux systems with a graphical display. Every Linux system has a package called XFree86 or Xorg providing this X11 display. But there is something only few know: X11 was originally designed for networking support! It's this ability that makes Linux remote-desktop support so unique, and flexible at the same time.

The real applications can be started from a central server, but their windows are displayed at the local X11 Server/Display. Remote applications do not send a screen image or window bitmap; they make a connection to the local X11 Server, and send drawing commands to it. This technique causes a lot of overhead for internet-based access, but at a local network it even allows OpenGL applications to operate at reasonable speed!

Using X11

To start an X11 application remotely, there are several techniques.

In the early days, X11 connections were sent directly over the Internet. This requires a system to have an X11 server listening to TCP port 6000, have that port open in the firewall, and relax the access restrictions of the local display! This is not desired, and SSH provides a better solution. SSH also provides some interesting options for X11 access, like encryption and compression.

X11 forwarding

SSH can initiate a secure tunnel.

Starting an X11 tunnel:
ssh -X -C username@hostname

The -X option activates X11 forwarding, and the -C options activates compression. Once the connection is established, any X11 application can be started from the command line. For example, xeyes or kwrite.

To enable X11 forwarding, the X11Forwarding setting needs to be changed in /etc/ssh/sshd_config. The settings require a restart of the SSH server, but this can be done from the active SSH session!

Enabling X11 tunnels: /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10  # this value is the default
X11UseLocalhost yes  # this value is the default

Note the difference between the files /etc/ssh/ssh_config and /etc/ssh/sshd_config. The first file is used for the client, the second for the server.

Just to let you know...
The -X option is explicitly used with the ssh command. It's possible to make this behavour default with a ForwardX11 yes line in /etc/ssh/ssh_config, but this is NOT recommended! That setting automatically opens the display to all remote systems clients are connected with.

The magical DISPLAY

At startup, each X11 application connects to it's display. What display the application connects to, depends on the DISPLAY environment variable. This setting can also be used to project an remote application at the local display. The command echo $DISPLAY can be used to read this value.

Changing the DISPLAY variable causes applications to connect to a different server. The drawing commands will also be sent to that particular server. The SSH server uses this. It emulates an X11 display at localhost:10.0, and forwards all received data.


XDMCP is the X11 Display Manager Control Protocol, and provides another way to establish a remote X11 connection. Using nothing but UDP port 177, XDMCP configures the session parameters for X11 connections. This eliminates the need to telnet to a machine, and set the DISPLAY variable manually. Once the connection is established, the login screen of the display manager appears.

Just to let you know...
Because XDMCP is inherently insecure, it should only be used in a trusted network. XDMCP can be abused easily, and all remote X11 applications use an unencrypted connection to connect to the local display.

The main advantage of XDMCP is the performance in fast networks, and ability to access the remote login screen. When the remote machine is configured, it initiates connections to the local display. There is little overhead because the data is not encrypted or tunneled. With plain X11 connections, it's possible to play simple OpenGL games like tuxracer over a local network! The X11/GLX commands are sent to the local machine and also rendered by the local graphics card.

Enabling XDMCP

To enable XDMCP, an Display Manager like xdm, gdm or kdm needs to run. One of these applications is likely running, they also provide the nice graphical login for Linux systems.

Only one of these applications need to be configured for XDMCP, and that's off course the one used for the graphical login.

The display manager server needs to be restarted after changing the configuration. This will also end your X session.

Restarting the display manager:
/etc/init.d/xdm restart
To enable XDMCP for XDM: /etc/X11/xdm/xdm-config
DisplayManager.requestPort: 0

The xdm-config file uses exclamination marks for comments, remove the comment for the requestPort line to enable XDMCP.

To enable XDMCP for GDM: /etc/X11/gdm/gdm.conf

Changing the GDM config file is much easier compared to XDM. It's also possible to start gdmconfig, go the tab "XDCMP" and enable the 'Enable XDMCP' checkbox.

To enable XDMCP for KDM: (kde path)/share/config/kdmrc

The location of the kdmrc file depends on the location KDE was installed. Unfortunately, this differs in each Linux distribution. It can be either /opt/kde3/share/config/kdmrc for most distributions, /usr/kde/3.3/share/config/kdmrc for Gentoo, and SuSE installs the file in /etc/opt/kde3/share/config/kdmrc.

Activating XDMCP

The setup is easy to test using Xnext. If the setup works, the login screen should appear in a few seconds.

Testing XDMCP with Xnest:
Xnest -query localhost :1

The :1 option starts Xnest at the second display; the local X server already uses the first display. The -query option specifies which XDMCP server to use, -broadcast can be used to detect all servers.

Replace Xnest with X to start a X11 server fullscreen.

Starting a new X server:
X -query localhost :1

blog comments powered by Disqus