Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. A widely used Transport Layer Protocol, SSH is used to secure connections between clients and servers. SSH was basically designed as a replacement for conventional Telnet and for unsecured remote shell protocols such as the Berkeley rlogin, rsh, and rexec protocols. These protocols send critical information, such as passwords, in plain text format, and are susceptible to interception and disclosure using methods like packet analysis or deep packet inspection. The encryption used by SSH provides confidentiality and integrity of data over an unsecured network, such as the Internet.
How Does SSH Work?
The SSH protocol employs a client-server model for authentication and encryption of data transferred between them.
Negotiating Encryption for the Session
- Version Exchange: When a TCP connection is made by a client, the server responds with the protocol versions it supports. If the client can match one of the acceptable protocol versions, the connection continues.
- Key Exchange Initialization: To kick off the key exchange, both sides send a SSH_MSG_KEX_INIT message to each other, with a list of cryptographic primitives they support with their preference. These primitives are basic building blocks, used to perform key exchange and bulk data encryption. The following table (Tab.1) shows some examples of cryptographic primitives.
- Diffie-Hellman Initialization: The key exchange begins by the client, generating an ephemeral key pair (private and associated public key) and sending its public key to the server in a, SSH_MSG_KEX_ECDH_INIT message (Fig. 2). The server checks the authorized_keys file of the account that the client is attempting to log into for the key ID. If strict key checking is enabled, and key is not found to be correct, the connection is rejected by the server thereby safeguarding the server from connecting with unknown clients. The key pair created will only be used during the key exchange and disposed afterwards. So, for an attacker it is extremely difficult to steal a private key while passively recording encrypted traffic. This property is called forward secrecy.
- Diffie-Hellman Reply: On receiving SSH_MSG_KEX_ECDH_INIT message, server generates its own ephemeral key pair. The shared secret key K is generated by server, with its own key pair and client’s public key. After successful generation of shared secret an exchange hash H is generated (Fig. 3). The exchange hash is signed by server to generate its signature HS (Fig. 4).
The exchange hash and its signature serve several purposes:
• The signature or verification loop, of the exchange hash and its signature enables the client to verify whether the server has ownership of the host private key. If yes, the client is connected to the correct server.
• A faster handshake is achieved by signing the exchange hash instead of input to exchange hash.
The exchange hash is generated by taking the hash (either SHA256, SHA384 or SHA512, as per the key exchange algorithm) of the following fields:
• Magics M
• Server host public key (or certificate) HPub
• Client public key A
• Server public key B
• Shared secret K
Magics consists of client version, server version, clients SSH_MSG_KEXINIT message and server SSH_MSG_KEXINIT message. With this information in hand, the SSH_MSG_KEX_ECDH_REPLY message can be constructed by the server from the following:
• ephemeral public key of the server B,
• the host public key of the server HPub,
• and the signature on the exchange hash HS.
After SSH_MSG_KEX_ECDH_REPLY is received by client, the client can calculate the secret K and the exchange hash H.
The client extracts the host public key (or certificate) from SSH_MSG_KEX_ECDH_REPLY and verifies the signature of exchange hash HS, hence proving the ownership of the host private key.
In order to prevent Man-in-the-Middle (MITM) attacks, after the signature is validated, the host public key (or certificate) retrieved is checked against a local database of the trusted hosts; if this key (or certificate) is not trusted the connection is terminated.
If you have ever seen a message like below (Fig. 5), it means that the key presented is not in your local database of known hosts.
Authenticating the User’s Access to the Server
The next stage involves authenticating the user and deciding access. There are various mechanisms for authentication but which mechanism to use depends upon what purpose the server is configured for.
The simplest is password authentication, but this is highly not recommended due to complexities and automated password breaking scripts.
The most popular and recommended alternative is the use of SSH key pairs. SSH key pairs are asymmetric keys. The public key is used to encrypt data that can only be decrypted with the private key. The public key can be freely shared, because, although it can encrypt for the private key, there is no method of deriving the private key from the public key.
Summary
SSH provides a secured encrypted channel for configuration of remote servers, established by agreed cryptographic primitives, and user authentication by symmetric key pairs.
The following diagram shows various stages of SSH handshake in establishing a secured channel that uses a password authentication mechanism.
