Layers of SSH Security
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 version 2 (and freely available DSA encryption keys). 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.
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. 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.
Authentication
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.
Connection
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.