The man pages for the OpenSSH tool [1] read like novels. Most users know only a fraction of the options, and this article, too, is restricted to just a few features. It provides tips on SSH multiplexing, tunneling, and various configuration files.

On My Mark!

One of the oldest SSH tricks is to define a command that SSH runs at the opposite end when executed; this saves you time and typing. The output appears in the local terminal:

<heike@home:~$> ssh huhn@example.com pwd
/home/huhn

The command displays the working directory for the user huhn after logging onto the example.com machine; in other words, the home directory. Multiple commands are also possible. It is important to quote the commands to make sure they really run on the remote system:

heike@home:~$ ssh huhn@example.com pwd;whoami
/home/huhn
heike
heike@home:~$ ssh huhn@example.com 'pwd; whoami'
/home/huhn
huhn

If you want SSH to run commands that require user interaction on the other machine, the t option is also necessary to start a pseudo terminal. This ensures that users remain logged in until the program is finished. In this way, you can, say, edit files with a text editor, use top to list the active programs list, or view log files with tail-f (Figure 1).

Figure 1: The SSH -t switch allows user interaction at the other end.

Well Prepared

If you juggle several accounts on remote servers that listen on different ports, or each use a different SSH key pair for authentication, you can specify the options each time you run SSH. However, you may find a separate ~/.ssh/config configuration file (Listing 1) more convenient.

Each line contains a keyword; this is followed by one or more arguments. In addition to options that apply only to one computer (sections following host name), global settings (host *) are also possible. Because SSH evaluates the information in sequence, the general settings are available at the end of the file. The man page lists all the options for ssh_config.

The example in Listing 1 contains two blocks for individual hosts. For the first computer (accessible via the alias ssh work), it defines that the SSH server listens on port 2220. Also, the IP address is entered instead of a hostname, and the key to be used is defined, which removes the need to try out all the keys – this speeds up the connection if several key pairs are located in the ~/.ssh directory.

The following applies for the second computer home.example.com: It is accessible using the home short name. CheckHostIP no prevents matching the IP address against the ~/.ssh/known_hosts file, which is useful for hosts with a changing, dynamically allocated IP.

In the general instructions, ServerAliveInterval 300 makes sure that the client sends a packet to the server after five minutes, to keep the connection alive and prevent a timeout. Additionally, the behavior of log is defined; users can choose from QUIET, FATAL, ERROR, INFO (standard), VERBOSE, Debug, DEBUG1, DEBUG2, and DEBUG3.

Data compression is turned on in this case, but this is only useful for hosts where the users are faced with a slow connection.

Bundled, We Are Strong

The multiplexing feature, which can send several signals via a TCP connection ensures a speed advantage. The SSH client uses an existing connection to the SSH server, which eliminates the handshake with the opposite end. You do not save time with the first SSH session, but from the second. Users control multiplexing with two options: ControlMaster and ControlPath:

ssh -o ControlMaster=yes -o ControlPath=~/.ssh/control-%h_%p_%r user@example.org

The statement ControlMaster = yes generates a master link, which other sessions with the same destination can use. ControlPath defines the required socket, composed of the file name control, the hostname (%h), the port (%p), and user name (%r) of the target computer. For the next connection to this host, users state the socket; ControlMaster is left at the default value (no):

ssh -o ControlPath=~/.ssh/control-%h_%p_%r user@example.org

The second link attempts to dock onto the first. Should that fail, the SSH client establishes a normal connection as a fallback solution. Listing 2 shows the comparison with the time for the who command measured on the remote machine with and without multiplexing. In a small test setup, the difference is not particularly impressive, but in larger environments the feature should have a positive effect.

The multiplexing configuration does not need to be enabled with -o; you can also do this in the SSH setup file. Besides the instructions, ControlMaster and ControlPath users can optionally define ControlPersist here; this determines how long the master connection waits for clients in the background after the first connection is done. Users can enter either no (master does not wait), yes (master waits forever) or a period of time in seconds. Listing 3 gives you an example.

By the way, it is not only SSH clients that benefit from the multiplexing feature, but also scp, rsync, git, and other commands that use the SSH protocol.