We've just covered a pile of chapters
on SSH configuration: is your head spinning yet? With so many
choices, you might be wondering which options you should use. How can
system administrators secure their systems most effectively with SSH?
When set up properly, SSH works well and invisibly, but sometimes a
good setup takes a few tries. In addition, there are some ways to
configure the software that are simply wrong. If you're not
careful, you can introduce security holes into your system.
In this chapter we present a recommended set of options for
compilation, server configuration, key management, and client
configuration. We assume:
You're running SSH on a Unix machine.
You want a secure system, sometimes at the expense of flexibility.
For instance, rather than tell you to maintain your
.rhosts files carefully, we recommend disabling
Rhosts authentication altogether.
Of course, no single configuration covers all the possibilities; that
is, after all, the point of configuration. This is just a sample
setup, more on the secure side, to give you a starting point and
cover some of the issues involved.
10.1. The Basics
Before you start configuring, make sure you're running an
up-to-date SSH version. Some older versions have known security holes
that are easily exploited. Always run the latest stable version, and
apply updates or patches in a timely manner. (The same goes for your
other security software.)
Always keep important SSH-related files and directories protected.
The server's host key should be readable only by root. Each
user's home directory, SSH configuration directory, and
files should be owned by the user and protected against all others.
Also, remember that SSH doesn't and can't protect against
all threats. It can secure your network connections but does nothing
against other types of attacks, such as dictionary attacks against
your password database. SSH should be an important part, but not the
only part, of a robust security policy. [Section 3.11, "Threats SSH Doesn't Prevent"]