This is the fourth blog post in the series of blog posts on the Secure Shell aka SSH. You can find the series index here. In the last post, we discussed how to customize SSH uing the server side configuration options. We discussed some of the most popular options and also shared location for list of full options available. In this blog post, we’ll discuss how we can customize the SSH session using some of the popular client side configuration options. Using these options can shape the way the connection is established and connection experience for the ssh clients.

Defining connection configuration files

SSH client obtains configuration data from the following sources in the following order:

• command-line options
• user’s specific configuration file (~/.ssh/config)
• system-wide configuration file (~/etc/ssh/ssh_config)

For each parameter, the first obtained value will be used. the configuration files contain section separated by Host specifications and that section is only applied for hosts that match one of the patterns given in the specification. The matched host is usually the one given on the command line.

Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end.

Saving server side connection information

It may happen that you want to save the server side connection information on your local machine for a variety of reasons. These connection information can be stored in the ~/.ssh/config file, which is read by your SSH client each time it is called.

If this file does not already exists, you can create it using an text editor such as nano or vi. Alternatively, you can use the touch command to create this file. Once the file is created, you can edit it using your favorite text editor available on the local machine.

Inside this file, you can define individual configuration options by introducing each with a Host keyword, followed by an alias. Beneath this and indented, you can define any of the directives found in the ssh_config man page.

One of the example configuration can be as below:

Host aws_london_test
  HostName ec2-203-0-113-25.compute-1.amazonaws.com
  Port 9200
  User demo

You can then establish ssh connection by simply supplying the alias name mentioned to the ssh command:

ssh aws_london_test

You can also use wildcards to match more than one host. Keep in mind that later matches can override earlier ones. Because of this, you should put your most general matches at the top.

Keeping connections alive to avoid timeout

As part of the reducing load on the ssh-server, some organizations can configure SSH server to expect a response from clients, say every X minutes. If the client does not supply a response within the stipulated time, the connection is timed out. After this, client has to re-establish connection and perform further operations.

SSH clients can be configured to send a dummy packet to SSH server to prevent this situation. To set this policy against all remote hosts, use the wildcard * after the Host keyword. If needed for specific servers, you can supply the alias for the remote connection. After this on next line, use the ServerAliveInterval directive followed by duration in seconds.

For example, below configuration can be used to send a packet every two minutes to remote ssh servers:

Host *
   ServerAliveInterval 120

Disabling Host Checking

By default, whenever you connect to a new server, you will be shown the remote SSH daemon’s host key fingerprint. It will then ask whether to proceed or not with the remote connection. It is configured so that you can verify that you are attempting to connect to the correct remote server.

In certain circumstances, you may wish to disable this feature. This can be a big security risk, so make sure you know what you are doing if you set your system up like this.

To make the change, define a section that will match all hosts using Host directive followed by wildcard *. Set the StrictHostKeyChecking directive to no to add new hosts automatically to the known_hosts file. Set the UserKnownHostsFile to /dev/null to not warn on new or changed hosts:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null

You can enable the checking on a case-by-case basis by reversing those options for other hosts. The default for StrictHostKeyChecking is ask:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null

Host aws_london_test
  HostName ec2-203-0-113-25.compute-1.amazonaws.com
  StrictHostKeyChecking ask
  UserKnownHostsFile /home/demo/.ssh/known_hosts
  User demo
  Port 9200

Multiplexing SSH sessions

SSH multiplexing reduces the time taken for establishing SSH connection, by re-using the same TCP connection for multiple SSH sessions. This removes some of work necessary to establish a new session.

To set up multiplexing, we’ll need to configure ControlMaster, ControlPath, and ControlPersist directives as shown below:

Host *
     ControlMaster auto
     ControlPath ~/.ssh/multiplex/%r@%h:%p
     ControlPersist 1

Note that the directory path specified in the ControlPath directive above, needs to be available. If its not already available, make one using the below command:

mkdir ~/.ssh/multiplex

Now, any sessions that are established with the same machine will attempt to use the existing socket and TCP connection. When the last session exists, the connection will be torn down after one second.

In case you need to bypass the multiplexing configuration temporarily, you can do so by passing the -S flag with none with the ssh command.

Above are some of the common client side configuration options for SSH. In next blog post, we’ll discuss about SSH tunneling, its benefits and how to configure/use the same.