Understanding SSH workflow

Telnet is used to communicate with a remote server. But, Telnet is not a secure communication protocol because it does not use any security mechanism and transfers the data over network/internet in a plain-text form including passwords and so any one could sniff the packets to get that important information. So, to overcome this issue SSH came into existence. Now, lets go ahead and understand SSH.

WHAT IS SSH?

SSH, also known as Secure Shell or Secure Socket Shell, is a network protocol that provides administrators with a secure way to access a remote computer. SSH establishes a cryptographically secured connection between two parties(client and server), authenticating each side to the other, and passing commands and output back and forth.

HOW SSH WORKS?

SSH protocol uses symmetric encryption, asymmetric encryption and hashing in order to secure transmission of information. The SSH connection between the client and the server happens in three stages:

1. Verification of the server by the client.
2. Generation of a session key to encrypt all the communication.
3. Authentication of the client.

Now, I will discuss about these stages in different sections.

1.VERIFICATION OF SERVER

The client initiates a SSH connection with the server. Server listens to default port 22(this port can be changed) for SSH connections. At this point, the server identity is verified. There are two cases:

1. If the client is accessing the server for first time, client is asked to authenticate server manually by verifying public key of server. Public key of server can be found using ssh-keyscan command or can be found at different places(WHERE?GOOGLE!).Once the key is verified, the server is added in known_hosts file in ~/.ssh directory on client machine. The known_hosts file contains the information about all the verified servers by the client.
2. If the client is not accessing the server for the first time, the server’s identity is matched with previously recorded information in known_hosts file for verification.

Figure : Snapshot of content of known_hosts file.

2.GENERATION OF SESSION KEY

After the server is verified, both the parties negotiate a session key using a version of something called the Diffie-Hellman algorithm. This algorithm is designed in such a way that both the parties contribute equally in generation of session key. The generated session key is shared symmetric key i.e. the same key is used for encryption and decryption.

3.AUTHENTICATION OF THE CLIENT

The final stage involves authentication of the client. Authentication is done using SSH key pair. As the name suggests, SSH key pair is nothing but a pair of two key to serve two different purposes. One is public key that is used to encrypt data and can be freely shared. The other one is private key that is used to decrypt data and is never shared with anyone.

After symmetric encryption has been established, the authentication of the client happens as follows:

1. The client begins by sending an ID for the key pair it would like to authenticate with to the server.
2. The server checks the authorized_keys file of the account that the client is attempting to log into for the key ID.
3. If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number and sends this encrypted message.
4. If the client has the correct private key, it will decrypt the message to obtain the random number that was generated by the server.
5. The client combines the obtained random number with the shared session key and calculates the MD5 hash of this value.
6. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.
7. The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.

Asymmetry of the keys allows authentication of the client because client can only decrypt the messages if it has the correct associated private key.

Figure : SSH debugging output message during login into a remote server.

CONCLUSION

The main idea behind this blog is to help the readers to understand what is ssh and what happens when the user tries to login into a remote server.

Hope you like it. Any suggestions are welcome and would love to hear them.