Adventure of the SSH Connection

Imagine you need to talk to a remote computer that’s far away. Maybe it’s sitting in a huge, noisy server room on the other side of the world. You want to send it some commands or pull some files. But the internet is like a crowded public corridor. It means everyone can hear what you say unless you whisper it through a secure channel. So, how can you “whisper” to this server through a secure channel?

Created by Samet Polat with Microsoft Designer

Using SSH of course. That’s exactly what SSH does: it gives you that secure, private channel to talk to other computers over the internet.

SSH — short for Secure Shell, is a protocol used to securely connect to another computer over a network. Once connected via SSH, you can securely access the remote machine’s command line, transfer files, run programs, or manage servers.

So, has this been the situation since the beginning of the universe? Where and when did a secure, private channel become a requirement?

Back in the 90s, people used older tools like Telnet to connect to remote machines. But, Telnet sent everything (including passwords) in plain text. It’s like “shouting” your password from the corridor.

In 1995, a Finnish researcher named Tatu Ylönen created the first version of SSH after a serious security issue at his university. It quickly spread, reaching thousands of people within months. In time, SSH became the standard way to securely access computers remotely. Later, SSH-2 was developed to further enhance security and performance.

So far so good. Now we can start diving deeper into the adventure! How does SSH work under the hood?

When you establish an SSH connection, the first step is the handshake. Think of it as a “friendly greeting” where both computers introduce themselves by exchanging protocol versions and supported encryption algorithms. In practical terms, the client starts by sending a connection request containing its SSH version and a list of the encryption methods it can use. The server takes this request and responds with its own SSH version information and a corresponding list of algorithms. This exchange ensures that both sides agree on a common set of rules before any sensitive information is shared, like two passengers agree on a common language for talking.

Created by Samet Polat with Microsoft Designer

Next comes key exchange, where each computer generates a unique secret. This process typically uses the Diffie-Hellman method. This method works like this: Both client and server agree on a large prime number and a base. Then, each side selects a random number. The client and server do some mathematical calculations with these values (prime number, base and random number) to calculate their own public values. When they exchange these public values, each side raises the received value to its secret number. Due to modular exponentiation math, both computers access the same common secret key without direct communication. This secret key is then used to generate the session key that encrypts the next communication. Even if an attacker capture the public values, they cannot calculate the common secret key without the random numbers — keeping your conversation safe.

Let’s walk through a basic version of Diffie-Hellman using small numbers for clarity:

Shared values:
Prime number: p = 23
Base: b = 5


The client selects a random number (c) and computes its public value (C):
c = 6
C = b^c mod p = 5^6 mod 23 = 15625 mod 23 = 8


The server selects a random number (s) and computes its public value (S):
s = 15
S = b^s mod p = 5^15 mod 23 = 30517578125 mod 23 = 2

They exchange their public values:
The client sends C = 8 to the server
The server sends S = 2 to the client

Now each computes the common secret key:
Client: key = S^c mod p = 2^6 mod 23 = 18
Server: key = C^s mod p = 8^15 mod 23 = 18

Both access same common secret key without sharing it over the network, 18.

Now it’s time for authentication — proving that you are who you say you are. SSH can use passwords, but it often uses a more secure method called public key authentication. In this process, your computer has a pair of keys: one public (shared with the remote computer) and one private (kept secret). When you try to connect, the remote computer sends a challenge that only your private key can solve. This is ensuring you’re allowed to join the conversation.

The process works as follows:

Get Samet Polat’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

You — usually generate a key pair using the ed25519 algorithm, which is a modern, fast and secure elliptic curve algorithm. This command generates two keys:

ssh-keygen -t ed25519 -C "your_email@example.com"

id_ed25519: your private key
id_ed25519.pub: your public key

They are mathematically related. Think of them like a lock and a key. The public key locks (encrypts) things and the private key unlocks (decrypts) them.

And this is exactly how the process works:

1. The server creates a random challenge (usually a large number or a string of random bytes).
2. It encrypts this challenge using your public key.
3. The encrypted challenge is sent to your client.
4. The client uses the private key to decrypt the challenge.
5. The client responds with a proof — typically a digital signature or the decrypted challenge itself.
6. The server verifies the response using the stored public key.
7. If the response checks out, access is granted.

After the connection is verified, all the communication between the two computers is encrypted using a symmetric key — the secret key both computers agreed on (in our example, it was 18). This means every command client type or every file you transfer is scrambled into a secure language that only the client and the server can understand. In a real SSH connection, once the common secret key is created, both machines pass it through a secure function (like SHA-256) to create a session key. This key is then used with a modern encryption algorithm like AES to lock and unlock all further communication. Just like that, the entire conversation is hidden behind a layer of mathematical secrecy. Even if someone intercepts the network traffic, all they’ll see is encrypted data that looks like meaningless — because they do not know the common secret key used to generate the session key.

To understand how encryption works, imagine the following simulated scenario:

1. From common secret to session key: During the Diffie-Hellman exchange, both client and server agree on a common secret key — like 18 in our case. Rather than using this directly, they run it through a secure function like SHA-256, which transforms it into a long, random-string. For example, 18 could become something like: f6a1b3c4d5e6f7a8b... This hashed output becomes the session key—an unguessable passcode generate from a simple common secret key.
2. Encrypting with AES: Now, whenever you send a command or transfer a file, this session key is used an encryption algorithm like AES to protect your data. AES takes a readable message — like “Transfer file 123” and scrambles it into something unintelligible, like A3F2C9B8D7E6... Without the session key, this encrypted data is just meaningless to anyone trying to intercept it.
3. Decryption with AES: When the server receives the scrambled message, it uses the same session key (the SHA-256 hash derived from 18) with AES to unlock the data. The process reverses the encryption, and the original clear text — “Transfer file 123” reappears on the server.

In short, starting with a simple secret key like 18, both machines create a powerful key (session key) through SHA-256. This key then becomes ingredient for AES to securely lock and unlock all your communication.

Now that we’ve discovered the secrets behind the magic of SSH, you’re officially an SSH Adventurer :) Whether you’re managing servers, transferring files, or simply connecting to a remote machine, SSH will always be your loyal and secure partner on your digital journey.

Until the next adventure — happy connecting!

The only real mistake is the one from which we learn nothing. — John Powell