ssh: Secure Shell

The ssh protocol is designed to be flexible and supports multiplexing of several communication channels within a single TCP stream. This design choice results in two effects: on one side the implementation of the protocol is much more elaborate than other TCP-based protocols, and on the other side the final user can exploit the added flexibility to achieve new goals. One of these goals is establishing secure communication channels between the X server and client applications. This feature is enabled by default whenever an ssh session is established.

The idea behind X11 forwarding is quite straightforward. The ssh application runs locally and is able to connect to the local X server without resorting to the network (via local Unix-domain sockets). Remote graphic programs, on the other hand, can connect locally to the sshd server which spawned the remote shell (via the loopback network interface). The remote sshd can encapsulate graphic data in the secure communication channel it owns, to complete the path linking the graphic application and the X server.

Figure 1 shows how a remote X application (running on a computer named sandra) securely connects to the local X server (on morgana).

Figure 1. Secure Connection to X Server

When you log into a remote computer through ssh, the DISPLAY environment variable is automatically set to a proper value, and no user intervention is needed to establish the graphical channel. The following screen-shot shows automatic assignment of DISPLAY:

morgana% ssh sandra env | grep DISPLAY
DISPLAY=sandra.systemy.it:10.0

It is apparent how any graphic program invoked on sandra by the ssh session will connnect to a local display (i.e., sandra:10).

The ssh/sshd programs can also forward other TCP channels, according to the user's needs. This capability can be activated by specifying command-line switches to the client ssh program. I won't describe the mechanisms here, as the manual page for ssh is well written.

The main problem when establishing a connection through an insecure network is performing reliable authentication. The ssh package is quite pedantic about authentication, and you'll be prompted for your password more frequently than usual. Typing passwords over and over is distressing and can be avoided by proper configuration of system files. Note also that any password you type is transmitted after establishing the encrypted communication channel.

You can type ssh -v (verbose) to get a report on what is happening. The information returned is very useful if you are unexpectedly prompted for a password. Now, let's look at the steps performed by ssh to authenticate a user in the remote server.

First, if the target account has no password, access is granted. If it does, different kinds of authentication engines are tried; each of which can be enabled or disabled into the server. For example, by default “PasswordAuthentication” and “RhostsRSAAuthentication” are enabled, and “RhostsAuthentication” is disabled.

The following is the sequence of actions when you try to log into a server running with the default configuration—which can be changed in /etc/sshd_config.

If your .rhosts file is correctly configured and you are still prompted for a password, the problem is most likely caused by RSA not succeeding. The easiest way to store the client's public key in the server is invoking ssh right away to connect back to the client computer. When confirming to continue the connection, the server (now acting as a client) downloads the public key of the local host (now acting as a server).