Configuring OpenSSH

---

With the installation path of /usr/local, the OpenSSH configuration files will be placed in /usr/local/etc. (This can be altered with the –sysconfdir= option, which is used to point to a different configuration path, such as /etc instead of /usr/local/etc. However, it's generally a good idea to leave the configuration files in the default location, unless there is a reason not to.)

There are a number of OpenSSH-related files in /usr/local/etc. Most of them contain the public and private keys for the server, for both the RSA and DSA systems. (RSA and DSA are public-key cryptographic algorithms. For information on these systems, consult a book on cryptography.) The public and private key files are ssh_host_dsa_key, ssh_host_rsa_key, ssh_host_dsa_key.pub, ssh_host_rsa_key.pub, ssh_host_key, and ssh_key_key.pub. Each of these files is in the /usr/local/etc directory. These files are automatically created when the software is installed, so you shouldn't have to do anything with them, unless you need to (such as if you're copying key files from another server). Another related file is /usr/local/etc/moduli, which is used as part of the cryptographic key exchange. Like the key files, you shouldn't need to do anything with this file.

The remaining files are /usr/local/etc/ssh_config and /usr/local/etc/sshd_config. These are the real "bread and butter" configuration files for OpenSSH. They configure the ssh client program and the sshd server program, respectively.

Upgrading OpenSSH

Eventually, an updated version of the OpenSSH package will be released, and you may wish to upgrade to it. In this case, you will need to upgrade the binary files without altering the configuration files. For example, you don't want to overwrite the private key files, or else your system's SSH identity will change, which can be very inconvenient to users. So, you need to be careful when upgrading to avoid losing the configuration files.

Most distributions include OpenSSH with the base installation and provide periodic upgrades if they are required. (For example, Red Hat Linux includes an RPM package for OpenSSH, and Red Hat periodically releases updated versions.) In these cases, the system's native packager will handle upgrading the binaries without altering the configuration files.

If you follow this book's example and install from source code, however, then you are relying on the source code package's installation scripts to copy the new binaries. Such scripts also install default copies of the configuration files. If the script isn't "smart" enough to see that copies are already installed, it may overwrite them. Therefore, it's always a good policy to back up your configuration files before installing a new piece of software. In the case of OpenSSH, the scripts are in fact smart enough to avoid overwriting existing copies of the configuration files, but a good administrator is always wary.

Configuring the ssh Client

The configuration file for the ssh client program is /usr/local/etc/ssh_config. (This file is also used by the other client programs, such as the "secure copy" scp program and the "secure FTP" sftp program.) The file contains a number of lines, each of which sets a different option that controls the run-time behavior of the OpenSSH client. The file format is straightforward. First, a host is specified via a "Host" line, and then options for that host are listed. If additional hosts are required, another Host line can be included followed by options for that host. A Host line consisting of "Host *" will match any host and so is effectively the default host.

After installation, /usr/local/etc/ssh_config will contain a typical default configuration. This is a pretty generic setup optimized for maximum security; that is, it leaves only basic options set and disables the "riskiest" features. For example, by default /usr/local/etc/ssh_config disables SSH agent forwarding, since it can be a security vulnerability if not used carefully. The default options are pretty reasonable, so generally it doesn't need to be modified that much.

OpenSSH supports a fairly large number of options, and most of these are related to the nuances of the cryptographic systems and algorithms it supports. Covering all these options and their nuances is really a task best left to the OpenSSH documentation, such as the manual page (which is quite detailed). However, it is worthwhile to cover two common examples of how to change an option from its default.

Enabling SSH Agent Forwarding

Recall that OpenSSH by default disables SSH agent forwarding. An SSH agent is a special program (usually named ssh-agent) that runs in the background and manages private keys for a user. The SSH agent is given the name of a program it is to run, and it then manages keys for that program and all children spawned by that program. The most common way to use this is to start ssh-agent up to manage a login shell, such as via the command ssh-agent bash. Once the special program ssh-add is used to add a key for ssh-agent to manage, all programs spawned by that shell will be able to automatically make use of the key.

Essentially, this means that the user won't have to enter the secret passphrase to unlock the key whenever it's used; the ssh-agent program will handle that. An example of using ssh-agent follows. If the user has her keys set up correctly on the local and remote servers (as described by the SSH documentation), then the following commands will set up and make use of an SSH agent:

 $ exec ssh-agent bash $ ssh-add (ssh-add will prompt the user for her passphrase) $ ssh my.remote.host 

(ssh will fetch the key from ssh-agent and log in automatically.)

After logging in to my.remote.host (which will happen automatically in the preceding example), the user may wish to log in to a second remote system, as if it were a relay or leapfrog. If SSH agent forwarding is enabled (and the remote server also allows it), then the agent that was initially set up on the local machine will again be used to log in to the second remote machine. If agent forwarding is disabled, then the user will have to type a passphrase or password.

If this seems confusing, then you now understand one reason why agent forwarding is disabled by default: It's simply too easy to get wrong. Another potential major issue is that enabling SSH agent forwarding exposes your account to additional weaknesses known as man-in-the-middle attacks, in which a trusted intermediate server (a "man in the middle") is compromised. The consequence of these weaknesses could be that a user accidentally puts his account in a state where an attacker could gain access to a remote system without even needing the user's password or SSH passphrase. Before you use SSH agents, you should carefully read and understand the OpenSSH documentation and configure your system and account properly.

If you do wish to use SSH agent forwarding, it will have to be enabled on your local system. To activate it, edit the following line in /usr/local/etc/ssh_config to be "yes" from the default "no." The change will take effect the next time a client program is run.

 ForwardAgent no 

Really, this is all a roundabout way of describing how to make a change in the ssh_config file. Each option has a value, and configuring the program is as simple as changing the values of options. However, OpenSSH is only as secure as its configuration, and it is very easy to configure OpenSSH in an insecure way. A wise administrator will read the OpenSSH documentation thoroughly before making any changes.

Disabling Strict Host Key Checking

Another option that is enabled in the default /usr/local/etc/ssh_config file is strict host key checking. OpenSSH implements the RSA and DSA public-key cryptosystems, meaning that both client and server have secret keys that allow them to unambiguously identify each other. However, if two computers have never "met" before (i.e., if they have not already exchanged their keys), then there is no way for them to verify each other's identities.

The OpenSSH clients have two options for handling this case. They can either abort connections to hosts with unknown keys or simply add the host's key to their list of known keys and issue a warning to the user. The first option is known as strict host key checking and can be enabled or disabled in the /usr/local/etc/ssh_config file. Using strict host key checking is more secure, since it helps prevent man-in-the-middle attacks similar to the one mentioned earlier; however, it's less convenient since it requires users to manually import keys from servers they trust (or it requires them to manually override the option on the command line). As always, it's a tradeoff between security and convenience, and you must carefully weigh your options. For more information on strict host key checking, consult the OpenSSH documentation at http://www.openssh.org.

If you decide to disable strict host key checking, the procedure is the same as for enabling SSH agent forwarding (discussed in the previous section). That is, locate the following line in /usr/local/etc/ssh_config and change the default "yes" value enabling strict key checking to "no."

 StrictHostKeyChecking yes 

Once this change has been made, the OpenSSH clients will start automatically adding the keys for remote servers to the user's list of known keys. A warning will be issued, but it becomes the responsibility of the user to be wary of untrustworthy remote hosts. (Note, however, that users can override this behavior in their own configurations. In general, ssh_config changes only the default options for clients.)

If disabling strict host key checking outright isn't palatable, there's also a third option, called "ask", that can be used as a compromise. When in this mode, the ssh clients will neither automatically add nor reject unknown keys. Instead, they'll prompt the user whenever an unknown key is encountered, asking whether it should be accepted. This requires user input, but it's less inconvenient than leaving strict host key checking on. To enable this option, simply use "ask" instead of "no" or "yes" in the preceding line.

Configurations in Binary Packages

The examples in this section on changing the default configurations of the OpenSSH clients and server demonstrate how to make such changes in general. The procedures will work on any installation of OpenSSH, whether it came from an installation from source code or from a binary installation such as an RPM file or a Slackware package. However, it's important to remember that these prepackaged binary installations are themselves set up with a specific configuration, which may not be the same as the default installation from the pristine OpenSSH source code. (For example, the OpenSSH installation that Red Hat ships with their distribution comes with strict host key checking already disabled, whereas it's enabled in the pristine installation.) So, always check to make sure a change you're making hasn't already been made, and don't be confused if you find that it has been. "Installer beware", so to speak.

Configuring the sshd Server

Configuring the sshd server is very similar to configuring the client programs. The /usr/local/etc/sshd_config file contains multiple lines, where each line sets the value of a particular option. As with ssh_config, sshd_config contains a reasonable set of default values. Changing the value of an SSH option is also as simple as editing the appropriate line in the file.

Again, OpenSSH can easily be rendered insecure by poor configuration options, so it is crucial to read and understand the OpenSSH documentation (such as the man page for sshd) before you make any configuration changes. However, one popular change is to enable X Window connection forwarding.

Enabling X Window Connection Forwarding

Frequently, a user will log in to a remote machine from an xterm or other shell that is running within an X Window environment. Usually, X programs that the user runs on the remote machine are intended to be displayed on the local machine physically present in front of the user. (After all, the program's not much use if the user can't see it.) Normally, the user would have to set a DISPLAY environment variable in order for the program to behave correctly; however, OpenSSH supports X connection forwarding to automatically handle this.

That is, the sshd server and ssh client can automatically establish a "tunnel" across which X programs on the remote machine can be run. When a client logs in, the sshd server on the remote system establishes a virtual or phantom X Window server that programs running on that system can connect to. This server simply relays any programs that connect to it back along the SSH connection to the user's own local system. Aside from the convenience of the automatically configured DISPLAY variable, the connection is also encrypted. Thus, X Window connection forwarding is a very useful and popular feature of OpenSSH.

However, under certain circumstances it can be a security hole (since it might prevent unwanted access to the user's X server, or even worse), so the default OpenSSH configuration has X connection forwarding disabled. To enable it, simply locate the following line in /usr/local/etc/sshd_config and change the default "no" to "yes":

 X11Forwarding no 

Note that this will enable X connection forwarding on your local machine, meaning that it will allow users who log into your system via SSH to make use of X connection forwarding. If you are a user who wishes to make use of X connection forwarding on a remote server, a similar change will have to be made on the remote server.

OpenSSH Configuration Summary

Once it's installed, configuring OpenSSH is generally pretty easy. It is, however, important to understand all the consequences of a configuration change before making it. OpenSSH is responsible for letting users log into a system, after all, and so a misconfiguration could potentially hand an attacker the keys to the system. However, the actual act of configuration is very easy: Just edit the appropriate line for the option that is to be updated.

---