SSH is a very common tool for people who have Raspberry Pis, but what most people don’t know about is what happens behind the screens to keep the SSH connection secure and our information safe from eavesdroppers.
Let’s start with the basics.
SSH stands for Secure SHell and it’s primarily used to remotely access the command line interface/terminal/shell of our Pi. Check out this article to learn more about the shell.
Before SSH became the standard for remote command line access, there was Telnet. Essentially, Telnet did the same thing as SSH, only it didn’t include any security measures. It was originally designed for closed networks like universities, but with the exponential expansion of the internet, security from bad actors became a serious concern for everyone with a server. To address this new need for security, Tatu Ylönen created the first version of SSH in 1995.
Our Raspberry Pi uses a version of SSH known as OpenSSH. Like all the software included on the Pi, it is open source and free to use.
Diffie-Hellman Key Sharing
The first step in establishing a secure connection with SSH is creating a shared cryptographic key for the client (remote computer) and server (Raspberry Pi). SSH uses something called a Diffie-Hellman key exchange (This method was created by Whitfield Diffie and Martin Hellman in 1976).
1. The client and server agree on a large prime number (seed) that will be used by both to generate an encryption key. For our example we’ll use a smaller prime number.
| Shared public seed |
|---|
| 97 |
2. The client and server agree on a method of manipulating the numbers (key generator). SSH typically uses the AES (Advanced Encryption Standard) which uses modular math to change the numbers. For our example, we’ll be using simple addition.
3. The client and server come up with their own large prime number (private key) that they do not share/is not transmitted over a network connection.
| Client | server | |
|---|---|---|
| Private Seed | 19 | 31 |
4. The public seed, the key generator, and the private seeds are used to produce two public keys which the server and client will exchange.
| Client | Server | |
|---|---|---|
| Public Seed | 97 | 97 |
| Key Generator | + | + |
| Private Seed | 19 | 31 |
| Public Key | 116 | 128 |
5. The client and server combine the exchanged public key, the key generator, and their original private key to generate a shared private key.
| Client | Server | |
|---|---|---|
| Exchanged Public Key | 128 | 116 |
| Key Generator | + | + |
| Private Seed | 19 | 31 |
| Shared Private Key | 147 | 147 |
This shared private key — which has never been transmitted over a network, and therefore unseen by anyone who might be watching our network traffic — is used to encrypt all traffic between the two computers for the rest of their session.
Asymmetric key exchange
Now that the two computers have a means of communicating in privacy, the next step is to establish the identity of the client computer. To do this, something called asymmetric key pairs are used.
Asymmetric encryption is when the method used to encrypt the message is different than the method used to decrypt it. In the key exchange described above, both the client and the server encrypt and decrypt using the same key; this is symmetric encryption.
In asymmetric cryptography, the key used to encrypt the message is known as a public key. The key used to decrypt that message is called the private key. The mathematics behind how this works are more complicated than the Diffie-Hellman key exchange described above so we’ll leave them for another article.
Once we have a public key and a private key, we put our public key on any computer that we are going to connect to. In this case we put the public key on our Pi.
The client computer asks the SSH server if it has our public key. If it does, the SSH server generates a random number, encrypts it using the public key we saved on the Pi, and sends it back to the client computer. The client uses the private key it has to decrypt the message and send it back to the server. If the message returned is the same as the message sent, then we’re granted remote access to the server.
But wait, there’s more
The final piece in the puzzle of SSH security is known as a hash function. Hash functions take data, apply a mathematical operation to it, and produce a Message Authentication Code (MAC). The nature of hash functions makes it nearly impossible to determine the original value of the data based solely on the hash output.
In our case, the data we’re putting into the hash function are the data being passed between the server and client plus the shared private key agreed upon using the Diffie-Hellman key exchange from earlier. When the client and the server exchange information, a MAC code is included with each transaction. When either the client or the server receive information, they produce their own MAC for the data received, and if the two MACs don’t match, the information is rejected.