The OpenSSH SSH daemon supports SSH protocols 1 and 2. Both protocols
are supported by default, though this can be changed via the Protocol op-
tion in sshd_config(5). Protocol 2 supports both RSA and DSA keys; pro-
tocol 1 only supports RSA keys. For both protocols, each host has a
host-specific key, normally 2048 bits, used to identify the host.
Forward security for protocol 1 is provided through an additional server
key, normally 768 bits, generated when the server starts. This key is
normally regenerated every hour if it has been used, and is never stored
on disk. Whenever a client connects, the daemon responds with its public
host and server keys. The client compares the RSA host key against its
own database to verify that it has not changed. The client then gener-
ates a 256-bit random number. It encrypts this random number using both
the host key and the server key, and sends the encrypted number to the
server. Both sides then use this random number as a session key which is
used to encrypt all further communications in the session. The rest of
the session is encrypted using a conventional cipher, currently Blowfish
or 3DES, with 3DES being used by default. The client selects the encryp-
tion algorithm to use from those offered by the server.
For protocol 2, forward security is provided through a Diffie-Hellman key
agreement. This key agreement results in a shared session key. The rest
of the session is encrypted using a symmetric cipher, currently 128-bit
AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The
client selects the encryption algorithm to use from those offered by the
server. Additionally, session integrity is provided through a crypto-
graphic message authentication code (hmac-sha1 or hmac-md5).
Finally, the server and the client enter an authentication dialog. The
client tries to authenticate itself using host-based authentication, pub-
lic key authentication, challenge-response authentication, or password
If the client successfully authenticates itself, a dialog for preparing
the session is entered. At this time the client may request things like
allocating a pseudo-tty, forwarding X11 connections, forwarding TCP con-
nections, or forwarding the authentication agent connection over the se-
After this, the client either requests a shell or execution of a command.
The sides then enter session mode. In this mode, either side may send
data at any time, and such data is forwarded to/from the shell or command
on the server side, and the user terminal in the client side.
When the user program terminates and all forwarded X11 and other connec-
tions have been closed, the server sends command exit status to the
client, and both sides exit.