A Typical Solaris Secure Shell Session
The Solaris Secure Shell daemon (sshd) is normally started at boot time when
network services are started. The daemon listens for connections from clients. A Solaris
Secure Shell session begins when the user runs an 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-side configuration
files. Command-line arguments can override the settings in the configuration files.
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 in Solaris Secure Shell
The server-side behavior of the sshd daemon is controlled by keyword settings in
the /etc/ssh/sshd_config file. For example, the sshd_config file controls which types of authentication are
permitted for accessing the server. The server-side behavior can also be controlled by
the command-line options when the sshd daemon is started.
The behavior on the client side is controlled by Solaris Secure Shell
keywords in this order of precedence:
Command-line options
User's configuration file, ~/.ssh/config
System-wide configuration file, /etc/ssh/ssh_config
For example, a user can override a system-wide configuration Cipher setting of
blowfish by specifying -c 3des on the command line.
Authentication and Key Exchange in Solaris Secure Shell
The Solaris Secure Shell protocols, v1 and v2, both support client user/host
authentication and server host authentication. Both protocols involve the exchange of session cryptographic keys
for the protection of Solaris Secure Shell sessions. Each protocol provides various methods
for authentication and key exchange. Some methods are optional. Solaris Secure Shell
supports a number of client authentication mechanisms, as shown in Table 19-1. Servers are
authenticated by using known host public keys.
For the v1 protocol, Solaris Secure Shell supports user authentication with passwords. The
protocol also supports user public keys and authentication with trusted host public keys.
Server authentication is done with a host public key. For the v1 protocol,
all public keys are RSA keys. Session key exchanges involve the use of
an ephemeral server key that is periodically regenerated.
For the v2 protocol, Solaris Secure Shell supports user authentication and generic interactive
authentication, which usually involves passwords. The protocol also supports authentication with user public
keys and with trusted host public keys. The keys can be RSA or
DSA. Session key exchanges consist of Diffie-Hellman ephemeral key exchanges that are signed in
the server authentication step. Additionally, Solaris Secure Shell can use GSS credentials for
authentication.
Acquiring GSS Credentials in Solaris Secure Shell
To use GSS-API for authentication in Solaris Secure Shell, the server must
have GSS-API acceptor credentials and the client must have GSS-API initiator credentials. Support is
available for mech_dh and for mech_krb5.
For mech_dh, the server has GSS-API acceptor credentials if root has run the
keylogin command.
For mech_krb5, the server has GSS-API acceptor credentials when the host principal that
corresponds to the server has a valid entry in /etc/krb5/krb5.keytab.
The client has initiator credentials for mech_dh if one of the following has
been done:
The client has initiator credentials for mech_krb5 if one of the following has
been done:
For the use of mech_dh in secure RPC, see Chapter 16, Using Authentication Services (Tasks). For the use
of mech_krb5, see Chapter 21, Introduction to the Kerberos Service. For more information on mechanisms, see the mech(4) and
mech_spnego(5) man pages.
Command Execution and Data Forwarding in Solaris Secure Shell
After authentication is complete, the user can use Solaris Secure Shell, generally by
requesting a shell or executing a command. Through the ssh command options, the
user can make requests. Requests can include allocating a pseudo-tty, forwarding X11 connections
or TCP/IP connections, or enabling an ssh-agent authentication program over a secure
connection.
The basic components of a user session are as follows:
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. On the server side, data is sent through the shell or a command.
When data transfer is complete, the user program terminates.
All X11 forwarding and TCP/IP forwarding is stopped, except for those connections that already exist. Existing X11 connections and TCP/IP connections remain open.
The server sends an exit status message to the client. When all connections are closed, such as forwarded ports that had remained open, the client closes the connection to the server. Then, the client exits.
