The SSH protocol allows any client and server programs built to the
protocol's specifications to communicate securely and to be used
interchangeably.
Two varieties of SSH currently exist. SSH version 1 contains several
patented encryption algorithms (however, several of these patents have
expired) and a security hole that potentially allows for data to be
inserted into the data stream. The OpenSSH suite under Red Hat Linux 7.3
uses SSH version 2.0 by default, although it also supports version 1. It
is recommended that you use SSH version 2-compatible servers and clients
whenever possible
SSH protocol versions 1 and 2 both add layers of security with each of
these layers providing its own type of protection.
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. Usually running over TCP/IP, 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 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:
Key exchange
The public key algorithm to be used
The symmetric encryption algorithm to be used
The message authentication algorithm to be used
The hash algorithm to be used
During the key exchange, the server identifies itself to the client
with a host key. Of course, if this client has
never communicated with this particular server before, then the
server's key will be unknown to the client. OpenSSH gets around this
problem by allowing the client to accept the server's host key the
first time an SSH connection occurs. Then, in subsequent connections,
the server's host key can be checked with a saved version on the
client, providing confidence that the client is indeed communicating
with the intended server.
 | Caution |
|---|
| | 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 you should verify the integrity of
a new SSH server by contacting the server administrator before connecting for
the first time.
|
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 particular
key and algorithm (the exact amount depends on the SSH
implementation), another key exchange occurs, which generates another
set of hash values and a shared secret value. Even if an attack is
able to determine the hash and shared secret values, the attacker
would have to determine this information each time a new key exchange
is made to continue to monitor the communication.
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 will then try to
authenticate itself to the server using any of the supported methods.
Servers 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-based authentication, are safe to use.
Most users requiring a secure shell will authenticate using a
password. Since the password is encrypted when moving over the the
transport layer, it can be safely sent across any network.
After a successful authentication over the SSH transport layer,
multiple channels are opened by
multiplexing[1] the single connection between the two systems. Each of
these channels handles communication for different terminal sessions,
forwarded X11 sessions, or other services seeking to
use the SSH connection.
Both clients and servers can create a new channel. Each channel is
then assigned a different number for 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.
