home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam

Book Home

Previous

Next

Chapter 10. A Recommended Setup

Contents:

The Basics
Compile-Time Configuration
Serverwide Configuration
Per-Account Configuration
Key Management
Client Configuration
Remote Home Directories (NFS, AFS)
Summary

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 .rhosts and .shosts 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"]