Chapter 5. Serverwide Configuration

After installing an SSH server (sshd ), it's time to make informed decisions about your server's operation. Which authentication techniques should be permitted? How many bits should the server key contain? Should idle connections be dropped after a time limit or left connected indefinitely? These and other questions must be considered carefully. sshd has reasonable defaults, but don't accept them blindly. Your server should conform to a carefully planned security policy. Fortunately, sshd is highly configurable so you can make it do all kinds of interesting tricks.

sshd may be configured at three levels, and this chapter covers the second one: serverwide configuration, in which a system administrator controls the global runtime behavior of the server. This includes a large, rich set of features, such as TCP/IP settings, encryption, authentication, access control, and error logging. Some features are controlled by modifying a serverwide configuration file, and others by command-line options passed to the server at invocation.

The other two levels of configuration are compile-time configuration (Chapter 4, "Installation and Compile-Time Configuration"), in which the server is compiled with or without certain functionality; and per-account configuration (Chapter 8, "Per-Account Server Configuration"), in which the server's behavior is modified by end users for their accounts only. We'll discuss the distinction between the three levels in more detail later in this chapter.

This chapter covers only the servers from SSH1/SSH2 and their derivatives OpenSSH and F-Secure SSH Server. Our reference implementations, however, are SSH1 and SSH2 for Unix. We've tried to indicate which features are found or not found in the various flavors of sshd, but these will certainly change as new versions appear, so read each product's documentation for the latest information.

5.1. The Name of the Server

The SSH server is named sshd1 for SSH1, sshd2 for SSH2, and sshd for OpenSSH. However, you may also be able to invoke sshd1 or sshd2 as sshd, because their Makefiles create a symbolic link called sshd. [Section 4.1.3, "Building and Installing SSH1"] [Section 4.1.4, "Building and Installing SSH2"] The link points to sshd2 if it's installed, otherwise sshd1 (the SSH1 Makefile doesn't supersede links installed by SSH2).

Some features in this chapter apply to sshd1 only, sshd2 only, OpenSSH's sshd only, or various combinations. We indicate this in the following ways:

If a command-line option applies to only one package, e.g., SSH1, we present the example using sshd1 and a comment. For instance, in SSH1 the -d option (debug mode) may appear alone:
```
# SSH1 only
$ sshd1 -d
```
If a command-line option applies only to SSH2, we use sshd2. Its -d option requires an argument:
```
# SSH2 only
$ sshd2 -d 2
```
We similarly identify OpenSSH-specific and F-Secure-specific features with comments:
```
# OpenSSH only
# F-Secure SSH only
```
If a command-line option works for several packages, we refer to the server as sshd. For example, the -b option (set the number of bits in the server key) is the same for SSH1 and OpenSSH, so you write:
```
# SSH1, OpenSSH
$ sshd -b 1024
```
Likewise, when we discuss configuration keywords, some apply to SSH1, SSH2, OpenSSH, or various combinations. We precede examples with a comment for clarity. For example, the MaxConnections keyword, which limits the number of available TCP/IP connections, is supported only by SSH2, so an example looks like:
```
# SSH2 only
MaxConnections 32
```


4.6. Summary		5.2. Running the Server

Chapter 5. Serverwide Configuration

Contents:

5.1. The Name of the Server