The SSH protocol allows any client and server programs built to the
protocol's specifications to communicate securely and be used
interchangeably.
Two different 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. It is recommended that you use
SSH version 2-compatible servers and clients, if at all possible.
OpenSSH includes support for both version 1 and 2. Combined with the
OpenSSL encryption libraries, OpenSSH provides a full-range of security
capabilities.
Both SSH protocol versions (1 and 2) use similar layers of security to
strengthen the integrity of the communication from several different
angles. Each layer provides its own type of protection, which when used
together with the others, strengthens the overall security of the
communication and makes it easier to use.
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,
verifying that the server is the correct machine for authentication,
and providing integrity protection of data packets as they are sent
and received. In addition, the transport layer can also provide
compression of the data, effectively speeding the transfer of information.
Once a client contacts a server using the SSH protocol, several
important points are negotiated so that the two systems can correctly
construct the transport layer:
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 |
|---|
| | The host key verification method used by OpenSSH is not perfect. An
attacker could masquerade as the server during the initial
contact, as the local system would not necessarily know the
difference between the intended server and the attacker at that
point. But, until a better host key distribution method becomes
widely available, this initially insecure method is better than
nothing.
|
SSH is designed to work with almost any kind of public key algorithm
or encoding format. After an initial key exchange creates two values
(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.
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.
Since servers can be configured to allow different types of
authentication, this method 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. Unlike other security authentication schemes, the password
is transmitted to the server in cleartext. However, since the entire
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 a different terminal session, forwarded X11
information, or any other separate service seeking to use the SSH
connection.
Both clients and servers can create a new channel, with each
channel being assigned a different number at each end. When one side
attempts to open a new channel, that side's number for the channel is
sent along with the request. This information is stored by the other
side and used to direct a particular type of service's communication
to that channel. This is done so that different types of sessions will
not affect one another and channels can be closed without disrupting
the primary SSH connection between the two systems.
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 host receives a message that the channel is able
to receive it.
Channels are particularly useful with X11 forwarding and TCP/IP port
forwarding with SSH. Separate channels can be configured differently,
perhaps to use a different maximum packet size or to transfer a
particular type of data. This allows SSH to be flexible in handling
different types of remote connections, such as dial-up over public
networks or high speed LAN links, without having to change the basic
infrastructure of the protocol. The client and server negotiate the
configuration of each channel within the SSH connection for the user
automatically.
