17.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 the client and
remote host is encrypted using a symmetric cipher.
The client authenticates itself to the server.
The remote client interacts with the remote host over the
The primary role of the transport layer is to facilitate safe
and secure communication between the two hosts at the time of
authentication and during subsequent communication. The
transport layer accomplishes this by handling the encryption and
decryption of data, and by providing integrity protection of
data packets as they are sent and received. The transport layer
also provides compression, speeding the transfer of information.
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 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 host key is unknown to the client and it
does not connect. OpenSSH gets around this problem by accepting
the server's host key. This is done after the user is notified
and has both accepted and verified 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 an 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, generating 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 is only useful for 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 methods.
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 supports based on its security model, and the client
can choose the order of authentication methods to attempt from
the available options.
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 do 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.