Solaris Secure Shell Administration (Reference)

This chapter describes how Solaris Secure Shell works from the administrator's point of view and how it is configured. The following is a list of the reference information in this chapter.

• A Typical Solaris Secure Shell Session

• Configuring the Solaris Secure Shell

• Maintaining Known Hosts on a Site-Wide Basis

• Solaris Secure Shell Files

A Typical Solaris Secure Shell Session

The Solaris Secure Shell daemon (sshd) is normally started at boot from the /etc/init.d/sshd script. The daemon listens for connections from clients. ASolaris Secure Shell session begins when the user runs the ssh, scp, or sftp command. A new sshd daemon is forked for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange with the client. These session characteristics are determined by client-side configuration files and server configuration files, and potentially command-line parameters. The client and server must authenticate themselves to each other. After successful authentication, the user can execute commands remotely and copy data between hosts.

Session Characteristics

The server-side behavior of the sshd daemon is controlled by keyword settings in the /etc/ssh/sshd_config file and potentially the command-line options when sshd is started. For example, sshd_config controls which types of authentication are permitted for accessing the server.

The behavior on the client side is controlled by the Solaris Secure Shell parameters in this order of precedence:

• Command-line options

• User's configuration file ($HOME/.ssh/config)

• System-wide configuration file (/etc/ssh/ssh_config)

For example, a user can override a system-wide configuration Cipher that is set to blowfish by specifying -c 3des on the command line.

Authentication

The steps in the authentication process for Solaris Secure Shell are as follows:

1. The user runs the ssh, scp, or sftp command.

2. The client and server agree on a shared session key.

   In v1, the remote host sends its host (RSA) key and a server (RSA) key to the client. Note that the server key is typically generated every hour and stored in memory only. The client checks that the remote host key is stored in the $HOME/.ssh/known_hosts file on the local host. The client then generates a 256 bit random number and encrypts it with the remote host's host key and server key. The encrypted random number is used as a session key to encrypt all further communications in the session.

   In v2, the remote host uses DSA in its host key and does not generate a server key. Instead, the shared session key is derived through a Diffie-Hellman agreement.

3. The local and remote hosts authenticate each other.

   In v1, the client can use .rhosts, .rhosts with RSA, RSA challenge-response, or password-based authentication. In v2, only .rhosts, DSA, and password-based authentication are permitted.

Command Execution and Data Forwarding

After authentication is complete, the user can use Solaris Secure Shell, generally by requesting a shell or executing a command. Through the ssh options, the user can make requests, such as allocating a pseudo-tty, forwarding X11 connections or TCP/IP connections, or enabling an ssh-agent over a secure connection. The basic components of a user session are as follows:

1. The user requests a shell or the execution of a command, which begins the session mode.

   In this mode, data is sent or received through the terminal on the client side, and the shell or command on the server side.

2. The user program terminates.

3. All X11 forwarding and TCP/IP forwarding is stopped. Any X11 connections and TCP/IP connections that already exist remain open.

4. The server sends the command exit to the client, and both sides exit.

Configuring the Solaris Secure Shell

The characteristics of a Solaris Secure Shell session are controlled by configuration files, which can be overridden to a certain degree by options on the command line.

Solaris Secure Shell Client Configuration

In most cases, the client-side characteristics of a Solaris Secure Shell session are governed by the system-wide configuration file, /etc/ssh/ssh_config, which is set up by the administrator. The settings in the system-wide configuration file can be overridden by the user's configuration in $HOME/.ssh/config. In addition, the user can override both configuration files on the command line.

The command line options are client requests and are permitted or denied on the server side by the /etc/ssh/sshd_config file (see ssh_config(4)). The configuration file keywords and command options are introduced in the following sections and are described in detail in the ssh(1), scp(1), sftp(1), and ssh_config(4) man pages. Note that in the two user configuration files, the Host keyword indicates a host or wildcard expression to which all following keywords up to the next Host keyword apply.

Host-Specific Parameters

If it is useful to have different Solaris Secure Shell characteristics for different local hosts, the administrator can define separate sets of parameters in the /etc/ssh/ssh_config file to be applied according to host or regular expression. This task is done by grouping entries in the file by Host keyword. If the Host keyword is not used, the entries in the client configuration file apply to whichever local host a user is working on.

Client-Side Authentication Parameters

The authentication method is determined by setting one of the following keywords to "yes":

• DSAAuthentication

• PasswordAuthentication

• RhostsAuthentication

• RhostsRSAAuthentication

The keyword UseRsh specifies that the rlogin and rsh commands be used, probably due to no Secure Shell support.

The Protocol keyword sets the Solaris Secure Shell protocol version to v1 or v2. You can specify both versions separated by a comma. The first version is tried and upon failure, the second version is used.

The IdentityFile keyword specifies an alternate file name to hold the user's private key.

The keyword Cipher specifies the v1 encryption algorithm, which might be blowfish or 3des. The keyword Ciphers specifies an order of preference for the v2 encryption algorithms: 3des-cbc, blowfish-cbc, and aes128-cbc. The commands ssh and scp have a -c option for specifying the encryption algorithm on the command line.