SSH or Secure Shell, is a remote administration protocol that allows users to control and modify their remote servers over the Internet through an authentication mechanism.
Provides a mechanism to authenticate a remote user, transfer entries from the client to the host, and retransmit the output back to the client. The service was created as a secure replacement for the unencrypted Telnet and uses cryptographic techniques to ensure that all communications to and from the remote server happen in an encrypted manner.
The image below shows a typical SSH window. Any Linux or macOS user can use SSH on their remote server directly from the terminal window. Windows users can take advantage of SSH clients like Putty. You can run shell commands the same way you would if you were physically operating the remote computer.

¿How does SSH work?
If you use Linux or Mac, then using the SSH protocol is very easy. If you use Windows, you will need to use an SSH client to open SSH connections. The most popular SSH client is PuTTY.
For Mac and Linux users, go to your program terminal and follow this procedure:
The SSH command consists of 3 different parts:
Shellssh { user } @ { host }
The SSH key command tells your system that you want to open a Secure and Encrypted Shell Connection. { user } represents the account you want to access. For example, you may want to access the user root, which is basically for the system administrator with full rights to modify anything on the system. { host } refers to the equipment you want to access. This can be an IP address ( for example, 244.235.23.19 ) or a domain name ( for example, www.xyzdomain.com ).
When you press enter, you will be asked to enter the password of the requested account. When you write it, nothing will appear on the screen, but your password is, in fact, being transmitted. Once you have finished writing, press enter one more time. If your password is correct, you will see a remote terminal window.
Understanding the different encryption techniques
The significant advantage offered by the SSH protocol over its predecessors is the use of encryption to ensure the secure transfer of information between the host and the client. Host refers to the remote server you are trying to access while the client is the equipment you are using to access the host. There are three different encryption technologies used by SSH:
one. Symmetric encryption
2. Asymmetric encryption
3. Hashing
Symmetric encryption
Symmetric encryption is a form of encryption in which a secret key both for encryption and for decryption of a message, both by the client and by the host. Indeed, anyone with the key can decrypt the message that is transferred.

Symmetric encryption is often called shared key ( shared key ) or shared secret encryption. Usually there is only one key that is used, or sometimes a key pair where one key can be easily calculated with the other key.
Symmetric keys are used to encrypt all communication during an SSH session. Both the client and the server derive the secret key using an agreed method, and the resulting key is never disclosed to third parties. The process of creating a symmetric key is carried out using a key exchange algorithm.
What makes this algorithm particularly secure is the fact that the key is never transmitted between the client and the host. Instead, the two teams share public data and then manipulate it to independently calculate the secret key. Even if another machine captures publicly shared data, it will not be able to calculate the key because the key exchange algorithm is not known.
Please note, however, that the secret token is specific to each SSH session, and is generated prior to client authentication. Once the key is generated, all packets moving between the two machines must be encrypted by the private key. This includes the password written to the console by the user, so credentials are always protected from network packet snoops.
There are several symmetric encrypted codes, including, but not limited to, AES ( Advanced Encryption Standard ), CAST128, Blowfish, etc. Before establishing a secure connection, the client and a host decide which encryption to use, publishing a list of supported ciphers in order of preference. The preferred encryption among those supported by clients that is present in the host list is used as two-way encryption.
For example, if two Ubuntu 14.04 LTS machines communicate with each other via SSH, they will use aes128-ctr as your default encryption.
Asymmetric encryption
Unlike symmetric encryption, asymmetric encryption uses two separate keys for encryption and decryption. These two keys are known as the public key ( public key ) and the private key ( private key ). Together, these keys form the pair of public-private keys ( public-private key pair ).

The public key, as the name suggests, is openly distributed and shared with all parties. While closely linked to the private key in terms of functionality, the private key cannot be mathematically calculated from the public key. The relationship between the two keys is highly complex: a message encrypted by the public key of a machine can only be decrypted by the same private key of the machine. This one-way relationship means that the public key cannot decrypt its own messages or decrypt anything encrypted by the private key.
The private key must remain private, that is, for the connection to be secure, no third party must know it. The strength of the entire connection lies in the fact that the private key is never revealed, since it is the only component capable of decrypting messages that were encrypted using its own public key. Therefore, any party with the ability to decrypt publicly signed messages must possess the corresponding private key.
Unlike general perception, asymmetric encryption is not used to encrypt the entire SSH session. Instead, it is only used during the symmetric encryption key exchange algorithm. Before starting a secure connection, both parties generate pairs of temporary public-private keys and share their respective private keys to produce the shared secret key.
Once secure symmetric communication has been established, the server uses the clients’ public key to generate and challenge and transmit it to the client for authentication. If the client can correctly decrypt the message, it means that it contains the private key necessary for the connection. And then the SSH session begins.
Hashing
Unidirectional hashing is another form of crypto used in Secure Shell Connections. The one-way hash functions differ from the previous two forms of encryption in that they are never intended to be decrypted. They generate a unique value of a fixed length for each input that does not show a clear trend that can be exploited. This makes them practically impossible to reverse.

It is easy to generate a cryptographic hash of a given input, but impossible to generate the hash input. This means that if a client has the correct input, they can generate the crypto hash and compare its value to verify if they have the correct input.
SSH uses hashes to verify the authenticity of the messages. This is done using HMACs, or hash-based message authentication codes. This ensures that the received command is not altered in any way.
While selecting the symmetric encryption algorithm, a suitable message authentication algorithm is also selected. This works similar to how encryption is selected, as explained in the symmetric encryption section.
Every transmitted message must contain a MAC, which is calculated using the symmetric key, the number of packet sequences and the content of the message. It is sent out of symmetrically encrypted data as the final section of the communications package.
¿How does the SSH protocol work with these encryption techniques?
The way SSH works is by using a client-server model to allow the authentication of two remote systems and the encryption of the data that passes between them.
SSH operates on TCP port 22 by default ( although this can be changed if necessary ). The host ( server ) listens on port 22 ( or any other assigned SSH port ) for incoming connections. Organize the secure connection by authenticating the client and opening the correct shell environment if the verification is successful.

The client must start the SSH connection by starting the TCP protocol with the server, ensuring a secure symmetric connection, verifying if the identity displayed by the server matches the previous records ( normally recorded in an RSA ) key warehouse file and presents the necessary user credentials to authenticate the connection.
There are two stages to establish a connection: first both systems must agree on encryption standards to protect future communications, and second, the user must authenticate. If the credentials match, user access is granted.
Session encryption negotiation
When a client tries to connect to the server through TCP, the server presents the encryption protocols and the respective versions it supports. If the client has a similar pair of protocol and version, an agreement is reached and the connection to the accepted protocol begins. The server also uses an asymmetric public key that the client can use to verify the authenticity of the host.
Once this is established, the two parties use what is known as the Diffie-Hellman Key Exchange Algorithm to create a symmetric key. This algorithm allows both the client and the server to reach a shared encryption key that will be used from now on to encrypt the entire communication session.
Here is how the algorithm works on a very basic level:
one. Both the client and the server match a very large prime number, which of course has no factor in common. This prime number value is also known as the seed value ( seed value ).
2. The two parts then agree on a common encryption mechanism to generate another set of values by manipulating the seed values in a specific algorithmic way. These mechanisms, also known as encryption generators, perform large operations on the seed. An example of such a generator is AES ( Advanced Encryption Standard ).
3. Both parties independently generate another prime number. This is used as a secret private key for interaction.
4. This newly generated private key, with the shared number and encryption algorithm ( for example, AES ), is used to calculate a public key that is distributed to the other computer.
5. The parts then use their personal private key, the shared public key of the other machine, and the original prime number to create a final shared key. This key is calculated independently by both teams, but will create the same encryption key on both sides.
6. Now that both parties have a shared key, they can symmetrically encrypt the entire SSH session. The same key can be used to encrypt and decrypt ( messages read: section on symmetric encryption ).
Now that the symmetrically secure encrypted session has been set, the user must be authenticated.
User authentication
The final stage before the user is granted access to the server is the authentication of their credentials. To do this, most SSH users use a password. The user is asked to enter the username, followed by the password. These credentials safely pass through the symmetrically encrypted tunnel, so there is no chance that they will be captured by a third party.
Although passwords are encrypted, it is not yet recommended to use passwords for secure connections. This is because many robots can simply perform brute force attack to crack easy or default passwords and thus gain access to your account. Instead, the recommended alternative is a pair of SSH keys.
It is a set of asymmetric keys used to authenticate the user without the need to enter any password.
Conclusion
Gaining an in-depth understanding of the underlying way SSH works can help users understand the safety aspects of this technology. Most people consider this process extremely complex and not very understandable, but it is much simpler than most think.
If you’re wondering how long it takes for a computer to calculate a hash and authenticate a user, well, it happens in less than a second. In fact, the most time is spent on data transfer over the Internet.
Hopefully, This SSH tutorial has helped you see how different technologies can be combined to create a robust system in which each mechanism has a very important role to play. Also, now you know why Telnet became a thing of the past as soon as SSH appeared.
Sources: Hostinger ; SSH Academy