Securing X, Part II: Tunneling X Traffic Through SSH

---

Now you’ve got better access control over your X server, but you still have all of your X data passing in the clear over the network. Even though X traffic can be difficult to reconstruct (considering graphics and mouse movements among other things), you might want to add encryption to the equation.

The Secure Shell (SSH) protocol allows for the forwarding of TCP connections through an SSH tunnel. If you have an implementation of a secure shell client that supports X11 forwarding, you can encrypt your X client connections back to the X server.

Let’s go back to the HOST1 and HOST2 example from earlier. Assume that the X server is on HOST1, and you want to run X client applications on HOST2 and display them on HOST1. First, both SSH implementations on HOST1 and HOST2 need to be built with X11 forwarding support (they are by default). Next, you’ll want to make sure that the SSH server on HOST2 has X11 forwarding enabled and that the SSH client on HOST1 has X11 forwarding enabled. You can check this by looking in the ssh_config and sshd_config files in your SSH configuration directories (location varies with installations but it’s typically /etc/ssh). Check for lines that say X11Forwarding or ForwardX11 and set them to "yes" if you want this to work.

Tip 

X11 forwarding on SSH clients can be turned on using the –X flag, regardless of what’s set up in the ssh_config file. X11 forwarding on SSH servers, however, is often turned off by default, and it can be changed only in the sshd_config file.

From HOST1, SSH to HOST2 using the –X flag to request X forwarding explicitly. Now take a look at your DISPLAY variable on HOST2 by issuing setenv | grep DISPLAY for csh and tcsh or set | grep DISPLAY for sh and bash. You should see something like this:

DISPLAY=HOST2:10.0

But wait a minute! The display number is 10 and the display host is HOST2. But you wanted X applications to display on HOST1. This DISPLAY variable is set up automatically by SSH when you connect using the –X option. The display number 10 on HOST2 is mapped to a local "proxy" X server back through your current SSH session to the actual X server display on HOST1. Go ahead—try running xclock on HOST2 and you should see a clock pop up on your screen on HOST1. And all your interaction with the application passes through the encrypted tunnel. Encryption is not terribly necessary if you are running a remote xclock application, but it might be more crucial if you were running a remote xemacs application.

Note 

It’s important that you remember not to use the –display option with any X commands you run through the SSH tunnel, because it will override the special "proxy" server that SSH sets up.

The SSH X forwarding even takes care of X authentication. In addition to setting up your display for its “proxy” X server automatically, the SSH client sets up “junk” xauth cookies and sends them to the SSH server. The server, in turn, puts the xauth cookies in your Xauthority file on the remotebox, automatically giving you access to your X server. In other words, if you started the X server on HOST1, the SSH client would tell the “proxy” X server on the SSH server to create the following Xauthority entry on HOST2:

HOST2:10 MIT-MAGIC-COOKIE-1  121812483b0b3f19367c1541062b472b

One nice thing about this behavior is that it keeps any real xauth cookies from ever being sent over the network. Only the junk cookie is passed back and forth (and it’s even encrypted). Connections that go back through the proxy will map the junk xauth cookie for HOST2:10 to a real xauth cookie for HOST1:0. This mapping takes place on the SSH client side. This allows only the authorized user who started the X server on HOST1 and made a successful SSH connection to HOST2 to forward X clients on HOST2 back to the X server through the SSH tunnel.

Still with us? This can get pretty complicated—so here’s a diagram that shows what’s going on.

---