Configuring the Secure Shell Software
Networks have never been secure. As the demand on open networks for remote access has grown, the risks of compromised systems and accounts has kept pace. Tools for securing networks, such as the Secure Shell software, were developed to counter the threats of password theft, session hijacking, and other network attacks. However, these tools need to be properly configured to the local environment.
This article provides recommendations on configuring two specific Secure Shell implementations for the Solaris™ Operating Environment (Solaris OE): OpenSSH and the Solaris™ Secure Shell software. The Solaris Secure Shell software is a component of the Solaris 9 OE release. For previous Solaris OE releases, OpenSSH is available. For information on building OpenSSH, consult the Sun BluePrints™ OnLine article "Building OpenSSHTools and Tradeoffs" (January 2003).
This article updates the configuration recommendations provided in the Sun BluePrints OnLine article "Configuring OpenSSH for the Solaris Operating Environment" (January 2002).
Security Policy
The primary purpose of security policy is to inform those responsible for protecting assets, such as hardware, software, and data, of their obligations. Management establishes the policy based on the risks it is willing to tolerate. The policy itself does not set goals but serves as a bridge between management's goals and the technical implementation. Configuration is the technical implementation.
The policy should guide the configuration. If you do not have a policy, I strongly recommend that you establish one. To help you develop a policy, refer to the Sun BluePrint OnLine article "Developing a Security Policy" (December 2001). There are a variety of resources available to assist in setting policy.
In configuring Secure Shell software, keep in mind two principles:
Defend-in-depth
Plan on failure
Let no single point of configuration or defense be the only gatekeeper for security.
Secure Shell software can, and should, be configured at multiple points (build-time, server configuration, and client configuration). No single misconfiguration should completely break the system security.
This article presents example client and server configurations in "Appendix: Configuration Files" on page 12. These example configurations are for a variety of environments ranging from a workstation to a DMZ bastion host, but not all of the options presented in these examples are described in this document. For more information, consult the vendor documentation.