When we send sensitive information/letters, we want it to be hidden from the outside world. So, we’ve made sure it is protected by sealing it in an envelope and sending it to a destination using the United States Postal Service (USPS). At least, this is how we used to send information. I’m not even entering a discussion around encrypting and Morse code, which used a more advanced level of secrecy.
Now, since we humans have evolved and adapted to the internet, we exchange information using a secure connection. Earlier, we used telnet to connect to a remote server using port 23. The problem was that we were sending the information via plain text, meaning that anyone who wanted to read the info could sniff the network and the info was compromised (the equivalent is that they could open the letter sent via the USPS and read it.)
This result is not what we wanted when we sent the original message. There has to be a safe way to send a message to a remote server, right? Absolutely, and the solution is to send it via the Secure Shell (SSH).
How SSH sends encrypted messages
So, I want to communicate securely using encrypted messages from client to server and vice versa. I accomplish this with SSH as follows. SSH establishes a secure connection between two hosts via port 22: Host-1 (the server) and Host (the client). After authenticating each other, they’ve enabled the safe exchange of messages.
SSH uses three different encryption types:
- Symmetric encryption
- Asymmetric encryption
I will briefly explain these types.
Also known as shared key encryption, symmetric encryption is usually a single key or a pair of keys is used for both encryption and decryption of a message. This key is used to encrypt the entire session of communication between a client and a server.
Both client and server agree upon a single method and generate a shared key, which is of course never disclosed to a third party, and hence it is used to send shared/secret key messages. The most interesting part about this method is that the key is never exchanged between a client and a server. Instead, each machine calculates the shared key independently using a method agreed upon earlier. Even if a third-party machine captures the data, it’s unable to decrypt because the method used to encrypt the data is unknown.
Unlike the above method, this method uses a pair of keys for encryption and decryption. These are known as public and private keys. The public key, as the name suggests, is distributed widely. The private key is closely related to the public key in terms of functionality but cannot be calculated just by knowing the public key.
The private key is an important factor in the entire communication since the secrecy depends on the fact that the private key is not revealed to any third party, and it’s the only key capable of decrypting the message, which is encrypted by its own public key. So, if any party wishes to decrypt and read the messages, they must possess the private key.
Let’s try this method using two systems. We’ll start with the workstation, which has two pairs of keys generated as below:
And hence, the server stores the workstation’s info in its
known_hosts file as:
After the server is verified, the server and client negotiate a session key using the Diffie-Hellman key exchange algorithm. This shared key is used for encryption and decryption.
The final stage is the authentication of the client, and this is done using the SSH key pair. The below diagram shows how this process happens:
When I issue the command
ssh -v firstname.lastname@example.org, here is what happens:
The purpose of this article was to make the user aware of how SSH establishes secure communication between two systems. Hopefully, I've offered some insight into that process.
[Want to learn more about SSH? Download the Advanced SSH Cheat Sheet.]