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:
- The initial terminal session is channelled through the tunnel. You are authenticated by the server and logged in.
- 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).
- 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.