Layers of SSH Security
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 8.0 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.
Both SSH protocol versions 1 and 2 add layers of security with each of these layers providing its own type of protection.
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 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. 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 that he will accept 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.
 | 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 or after a host key has changed. |
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 attack is able to determine the hash and shared secret value, he would have to determine this information each time a new key exchange is made in order to monitor the communication.
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.
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.
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 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.