SSH X11 Forwarding

By far, the easiest way to use X service on a remote host is via the ssh port forwarding mechanism. For this, ssh creates an encrypted tunnel between the remote and local host. Then the remote X server looks like its local.

To activate X11 forwarding, the server on the remote side must have that feature enabled. The configuration file is normally /etc/ssh/sshd_config. The 2 important configuration keys are at the bottom:

# This is ssh server systemwide configuration file.
Port 22
Protocol 2,1
ListenAddress 0.0.0.0
HostKey /etc/ssh/ssh_host_ed25519_key
PermitRootLogin no
StrictModes yes
X11Forwarding yes
X11DisplayOffset 10

Once these are set you can ssh into the remote host and fire up your X11 applications with impunity. Here is an example:

[joe@client.acme]: ssh -X chico.acme
 Last login: Sun Mar  2 21:50:23 2003 from groucho.acme

[joe@chico.acme]: xterm &
[joe@chico.acme]: echo $DISPLAY

  chico.acme:10.0

And it is all encrypted! How cool is that?

Exercises

  1. Use the X11 forwarding to login to the remote server and start an Xterm interactively on localhost. An ssh tunnel is created between the 2 machines and a local DISPLAY variable (on server.acme) is setup that connects to the originating client’s X-server:

    [joe@client.acme]: ssh server.acme

Enter passphrase for key '/home/joe/.ssh/id_ed25519': ********

[joe@server.acme]: echo $DISPLAY
   localhost:10.0
[joe@server.acme]: xterm &

    You should now see an xterm that is from joe@server.acme. Notice that the DISPLAY variable is strangely set to a local value of server.com.

  2. How then does it show up in your client box? Discuss with others and do some investigation. Once convinced, remove the foreign xterm.

Dangers of X11 Forwarding

As usual, each technology has its weaknesses that can be exploited by those with the ability and desire. X11 Forwarding, if cracked, can lead to every conceivable problem that is inherent in X11 itself including every sort of X11 highjacking. Here is a section paraphrased directly from the SSH manual page:

The options are as follows:
  -x  Disables X11 forwarding.
  -X  Enables X11 forwarding. Use with caution. Users with the
      ability to bypass file permissions on the remote host can access
      the local X11 display through the forwarded connection. An attacker
      may then be able to perform activities such as keystroke
      monitoring.

Also, users must be carefull not to set the DISPLAY variable by hand (unless you really know what you are doing) to any value besides the default value assigned by ssh. From another part of the same ssh manual, again paraphrased:

ENVIRONMENT

  **Ssh** will normally set the DISPLAY environment variable which indicates
  the location of the X11 server. It is automatically set by ssh to point
  to a value of the form ``hostname:n'' where hostname indicates the host
  where the shell runs. The user should normally not set DISPLAY explicitly,
  as that will render the X11 connection insecure (and requires manually
  copying of any required authorization cookies).

As always, use this technology with extreme caution.

Exercises

  1. Display the xauth information on server.acme. What can you conclude about xauth and X11 forwarding if anything?

  2. Log into your server’s machine with X11 Forwarding enabled.

  3. Start an xterm from the remote machine. Check that the DISPLAY variable on the remote box is set correctly.

  4. Think of 2 ways X11 Forwarding can be exploited to obtain system passwords.

  5. How might you guard against keystroke monitoring in the case that X11 forwarding is compromised?

  6. Search the security page for X11 exploits at OpenSSH’s site: http://www.openssh.org/security.html.

  7. Search the security page for Agent Forwarding exploits at OpenSSH’s site: http://www.openssh.org/security.html. Discuss issues with your neighbor.