Iscriviti per attivare i feed RSS

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.

Encryption types

SSH uses three different encryption types:

  • Symmetric encryption
  • Asymmetric encryption
  • Hashing

I will briefly explain these types.

Symmetric encryption

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.

Asymmetric encryption

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:

SSH and asymmetric encryption: generating key pairs. I then initiate the connection from the server to the workstation:

And hence, the server stores the workstation’s info in its known_hosts file as:

SSH and asymmetric encryption: key information in known_hosts.

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:

SSH and asymmetric encryption: client authentication.

When I issue the command ssh -v [email protected], here is what happens:

SSH and asymmetric encryption: established connection.

Conclusion

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.]


Sull'autore

I work as a Solutions Engineer at Red Hat and my day-to-day work involves OpenShift and Ansible. I'm highly passionate about open source software, cloud, security, and networking technologies.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Ricerca per canale

automation icon

Automazione

Novità sull'automazione IT di tecnologie, team e ambienti

AI icon

Intelligenza artificiale

Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque

open hybrid cloud icon

Hybrid cloud open source

Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido

security icon

Sicurezza

Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti

edge icon

Edge computing

Aggiornamenti sulle piattaforme che semplificano l'operatività edge

Infrastructure icon

Infrastruttura

Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale

application development icon

Applicazioni

Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili

Virtualization icon

Virtualizzazione

Il futuro della virtualizzazione negli ambienti aziendali per i carichi di lavoro on premise o nel cloud