About Secure X Window Sessions

The mechanics of securing the X protocol with Secure Shell are similar to the mechanics of securing other third-party protocols by forwarding their connections through Secure Shell tunnels. Though the mechanics are similar, the process of rerouting the X protocol (as opposed to the IMAP protocol, for example) is made simpler by Secure Shell’s built-in ability to handle X communications.

If you enable X11 port forwarding in a tunnel profile, when you start the tunnel, the Connectivity Secure Shell engine requests X forwarding upon connection to the Secure Shell server. If the server supports X forwarding, the process continues as follows:

1. The initial terminal session is channelled through the tunnel. You are authenticated by the server and logged in.
2. Because X11 forwarding is enabled in the tunnel profile, the Secure Shell server takes on the roll of a Proxy X server, and forwards the DISPLAY in the remote shell to point to itself (the X proxy display).
3. When you launch an X client application, the X client connects to the X proxy server (the Secure Shell server), which then instructs the Connectivity Secure Shell engine to act as proxy X client. The X protocol is sent through the tunnel between the Connectivity Secure Shell engine and the Secure Shell server over a second channel.

Even though these socket connections are not encrypted, they are secure because they do not traverse the external network. The X client on the remote server uses a socket connection on localhost to the proxy X server established by the Secure Shell server. The X protocol data are then transferred through the external network via the encrypted Secure Shell tunnel. The Connectivity Secure Shell engine sends this data to the proxy X client, which uses a socket connection on localhost to the actual X server (Exceed) running on the user's workstation.