After installing an SSH server (sshd),^[42] 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.

This chapter covers serverwide configuration, in which a system administrator controls the global runtime behavior of the SSH 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.

Serverwide configuration is just one of three levels for controlling the behavior of SSH servers. The other two levels are compile-time configuration (Chapter 4), in which the server is compiled with or without certain functionality; and per-account configuration (Chapter 8), 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. [5.2]

This chapter covers only the OpenSSH and Tectia servers, focusing on the Unix implementations (including Unix variants such as Linux and OpenBSD). We’ve tried to indicate which features are present or absent in each flavor of sshd, but these will certainly change as new versions appear, so read each product’s documentation for the latest information.