Configuring OpenSSH for the Solaris Operating Environment
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 OpenSSH, were developed to counter the threats of password theft, session hijacking, and other network attacks. However, these tools come with the price of planning, configuration, and integration. This article provides recommendations for configuring and managing OpenSSH.
Specifically, this article deals with client and server configuration, key handling, and the integration of OpenSSH into existing environments that run the Solaris™ Operating Environment (Solaris OE.) For details about the compilation of OpenSSH's components, consult the Sun BluePrints™ OnLine article "Building and Deploying OpenSSH for the Solaris Operating Environment" (July, 2001).
This article does not discuss general OpenSSH usage. Consult the OpenSSH man pages and SSH, The Secure Shell for that information. For technical details about the underlying protocols, refer to the Internet Drafts of the Secure Shell (SECSH) working group.
This article was drafted using OpenSSH 2.9p2.
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 a security 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.
OpenSSH was designed to be a secure replacement for unsafe network commands such as rlogin, rsh, rcp, telnet, and ftp. The way you configure OpenSSH should reflect a site's local security policy. For example, you might consider whether password authentication is appropriate, or whether a more rigorous two-factor (public-key based) authentication is required. Further, you might consider whether the policy allows OpenSSH to tunnel TCP and X windows connections and whether it allows for remote access to internal web sites. Again, OpenSSH configuration should match local policy.
If a site does not have a security policy, one should be crafted before configuring OpenSSH. For guidance on crafting a security policy, consult the references in the Bibliography.