18.3. Event Sequence of an SSH Connection
The following series of events help protect the integrity of SSH
communication between two hosts.
A cryptographic handshake is made so that the client can verify
that it is communicating with the correct server.
The transport layer of the connection between client and remote
host is encrypted using a symmetric cipher.
The client authenticates itself to the server.
the remote client can now interact safely with the remote host
over the encrypted connection.
18.3.1. Transport Layer
The primary role of the transport layer is to facilitate safe and
secure communication between the two hosts at the time of and after
authentication. The transport layer accomplishes this by handling the
encryption and decryption of data and providing integrity protection
of data packets as they are sent and received. In addition, the
transport layer provides compression, speeding the transfer of
Once an SSH client contacts a server, key information is exchanged so
that the two systems can correctly construct the transport layer. The
following steps occur during this exchange:
Keys are exchanged
The public key encryption algorithm is determined
The symmetric encryption algorithm is determined
The message authentication algorithm is determined
The hash algorithm to be used is determined
During the key exchange, the server identifies itself to the client
with a unique host key. If the client has never
communicated with this particular server before, the server's key will
be unknown to the client and it will not connect. OpenSSH gets around
this problem by accepting the server's host key after the user is
notified and verifies the acceptance of the new host key. In
subsequent connections, the server's host key is checked against the
saved version on the client, providing confidence that the client is
indeed communicating with the intended server. If, in the future, the
host key no longer matches, the user must remove the client's saved
version before a connection can occur.
It is possible for an attacker to masquerade as the SSH server
during the initial contact since the local system does not know the
difference between the intended server and a false one set up by an
attacker. To help prevent this, verify the integrity of a new SSH
server by contacting the server administrator before connecting for
the first time or in the event of a host key mismatch.
SSH is designed to work with almost any kind of public key algorithm
or encoding format. After an initial key exchange creates a hash value
used for exchanges and a shared secret value, the two systems
immediately begin calculating new keys and algorithms to protect
authentication and future data sent over the connection.
After a certain amount of data has been transmitted using a given key
and algorithm (the exact amount depends on the SSH implementation),
another key exchange occurs, which generates another set of hash
values and a new shared secret value. Even if an attacker is able to
determine the hash and shared secret value, this information would be
useful for only a limited period of time.
Once the transport layer has constructed a secure tunnel to pass
information between the two systems, the server tells the client the
different authentication methods supported, such as using a private
key-encoded signature or typing a password. The client then tries to
authenticate itself to the server using one of these supported
SSH servers and clients can be configured to allow different types of
authentication, which gives each side the optimal amount of
control. The server can decide which encryption methods it will
support based on its security model, and the client can choose the
order of authentication methods to attempt from among the available
options. Thanks to the secure nature of the SSH transport layer, even
seemingly insecure authentication methods, such as a host and
password-based authentication, are safe to use.
After a successful authentication over the SSH transport layer,
multiple channels are opened via a technique
called multiplexing. Each of these channels handles communication for
different terminal sessions and for forwarded X11 sessions.
Both clients and servers can create a new channel. Each channel is
then assigned a different number on each end of the connection. When
the client attempts to open a new channel, the clients sends the
channel number along with the request. This information is stored by
the server and is used to direct communication to that channel. This
is done so that different types of sessions will not affect one
another and so that when a given session ends, its channel can be
closed without disrupting the primary SSH connection.
Channels also support flow-control, which
allows them to send and receive data in an orderly fashion. In this
way, data is not sent over the channel until the client receives a
message that the channel is open.
The client and server negotiate the characteristics of each channel
automatically, depending on the type of service the client requests
and the way the user is connected to the network. This allows great
flexibility in handling different types of remote connections without
having to change the basic infrastructure of the protocol.