Running Remote Applications

The -display option allows a single application to display remotely, but what about an entire desktop? It is possible to start a graphical login remotely over XDMCP using the Xnest or Xephyr X servers. These servers act like application windows on your local display but connect to the remote display manager (GDM) to offer up a graphical login. GNOME doesn't include these servers, and on most Linux distributions, they are likely not installed by default. However, if you do a quick search of your distribution's software repositories, you should find packages similar to these Fedora-specific packages: xorg-x11-server-Xephyr and xorg-x11-server-Xnest.

After installation, the servers can be run manually to connect to a remote system:

Xnest :10 -query <host-with-gdm-configured> -geometry 1024x768
Xephyr -query <host-with-gdm-configured> -screen 1024x768 :1

Figure 2. Xephyr-Based Remote Desktop Running Evolution

Experiments with both shows that Xephyr (Figure 2), the more modern and more actively developed of the two, was more stable. Unfortunately, logging out of a session prevented further connections. That may be because GDM was configured to allow only a single session from a remote system and may be fixed with additional research into GDM configuration. In these tests, however, the only solution was to restart GDM on the remote host.

XDMCP via GDM acts as a conduit for remote applications to display on a local machine. This means it does not control remote desktops. In fact, there doesn't need to be anyone logged in to the remote system at all, although GDM does need to be running. Because it doesn't take control of an existing X session remotely, it is possible to have a different display size on the local display. For example, if the remote system provides only a display resolution of 800x600, it still would be possible to display at 1024x768 on the local display using a Xephyr and a GDM/XDMCP-managed connection. It also means you can use different desktop environments (GNOME, KDE, Xfce or others) for the remote and locally displayed sessions.

By far, the easiest of the three methods for remote application display is to use SSH. SSH is the secure shell, a tool for connecting to remote systems using encrypted communications. Linux systems use the open-source OpenSSH implementation of SSH. This package offers X11Forwarding, a configurable option in the server and client (the SSH server and client) that end users utilize with the -X command-line option.

SSH uses a client/server architecture. The server side is the remote system, and the client is the local system (the configuration that we normally think of as client/server and the opposite of X). The remote server must be configured to allow X11 forwarding. This is done by enabling the X11Forwarding option in /etc/ssh/sshd_config:

...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE
AcceptEnv LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE
AcceptEnv LC_MEASUREMENT LC_IDENTIFICATION LC_ALL LANGUAGE

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
...

X11 forwarding also can be enabled on a per-user basis in this file by placing the X11Forwarding option after a user specification:

...
Match User bilbobaggins
   X11Forwarding no
...

These changes will not take affect until the SSH server is restarted. If your distribution provides it, the service command is the easiest way to do this:

sudo service sshd restart

The client-side configuration, found in /etc/ssh/ssh_config, requires enabling the Forward11Trusted option. This is enabled by default on Fedora systems, although other distributions may require the option to be enabled manually:

...
ForwardX11Trusted yes
...

Note that the location of the SSH client and server configuration files may vary with different Linux distributions. Consult the OpenSSH package for your distribution to find the configuration files.

Once the server and client sides are configured for SSH, a user can use X11Forwarding by adding the -X option to an SSH login. The -X option passes the required DISPLAY information to remote applications, which automatically open on the local display. Note that using SSH X11Forwarding means the remote application should not use the -display option nor should the DISPLAY environment variable be set. SSH will take care of all of that automatically.

SSH X11Forwarding does not require the remote machine to be running GDM or an X server. This means remote systems can be run in headless mode, which means they have no display at all. Instead, users log in remotely using ssh -X, run graphical applications on the remote system and have them display locally. This places far less load on the remote system than using the GDM-based remote application display.

Although in most instances, you will need to have an X server installed on the remote system, because most X applications, which are on the remote system, will need the associated X libraries, and most package managers will end up installing the entire X server to provide them:

ssh -X <remote host>
# login to remote host succeeds...
xterm -geometry 80x50