You type ssh user@server and two seconds later you have a shell on a remote machine. In those two seconds, a remarkable amount of cryptography happens.

Step 1: TCP Connection

SSH runs over TCP, usually port 22. Your client opens a TCP connection to the server. Nothing encrypted yet — just a raw socket.

Both sides immediately exchange version strings:

Client: SSH-2.0-OpenSSH_9.6
Server: SSH-2.0-OpenSSH_9.5

This negotiates the SSH protocol version. SSH-2.0 is the only version you should ever see. SSH-1 has known vulnerabilities and is effectively dead.

Step 2: Key Exchange (The Hard Part)

This is where the magic happens. The client and server need to agree on a shared secret — over an insecure connection, where anyone could be listening.

They use Diffie-Hellman key exchange (or its elliptic curve variant, ECDH). The simplified version:

1. Both sides agree on a large prime number and a generator
2. Each side generates a random private number
3. Each side computes a public value and sends it to the other
4. Each side combines their private number with the other’s public value
5. Both arrive at the same shared secret — without ever sending it over the wire

An eavesdropper sees the public values but can’t compute the shared secret. This is the mathematical foundation of SSH security.

Step 3: Server Authentication

How do you know you’re talking to the real server and not an attacker? The server proves its identity using its host key.

The first time you connect, you see:

The authenticity of host 'server.com' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf123456...
Are you sure you want to continue connecting? (yes/no)

When you type “yes,” the fingerprint is saved in ~/.ssh/known_hosts. On future connections, your client checks that the server’s key matches. If it doesn’t, you get the scary warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This means either the server was reinstalled or someone is intercepting your connection.

Step 4: Encryption Begins

Using the shared secret from the key exchange, both sides derive encryption keys. From this point on, everything is encrypted. The algorithms are negotiated during the handshake — typically AES-256 for encryption and HMAC-SHA256 for integrity.

Every packet is encrypted, authenticated, and sequenced. An attacker can’t read, modify, or replay any data.

Step 5: User Authentication

Now the server knows the client is talking to the right server. But the server still doesn’t know who the user is. SSH supports several authentication methods:

Password authentication — The client sends the password (encrypted, of course). Simple but less secure — passwords can be guessed.

Public key authentication — The preferred method. Your public key is in ~/.ssh/authorized_keys on the server. The server sends a challenge, your client signs it with your private key, and the server verifies the signature. Your private key never leaves your machine.

# Generate a key pair
ssh-keygen -t ed25519

# Copy public key to server
ssh-copy-id user@server

Certificate authentication — Like public keys, but managed by a certificate authority. Common in large organizations.

Step 6: The Channel

After authentication, SSH opens a “channel” — a logical connection within the encrypted tunnel. Your shell session is one channel. But SSH can multiplex multiple channels over a single connection:

• Shell sessions
• Port forwarding (ssh -L 8080:localhost:80 server)
• SFTP file transfers
• X11 forwarding

Each channel has its own flow control and can be opened/closed independently. This is why you can run scp while an SSH session is open — they share the same encrypted connection.

Why SSH Keys Are Better Than Passwords

• No secret transmitted — With passwords, the password crosses the network (encrypted, but still). With keys, only a signature crosses the network. Even if someone breaks the encryption, they get a one-time signature, not your key.
• No brute force — A 256-bit ED25519 key has more possible values than atoms in the universe. Passwords have maybe 40-60 bits of entropy.
• No phishing — You can’t trick someone into typing their private key into a fake login page.

The Full Timeline

0ms    — TCP connection established
50ms   — Version exchange
100ms  — Key exchange (Diffie-Hellman)
150ms  — Server authentication (host key check)
200ms  — Encryption active
250ms  — User authentication (public key)
300ms  — Channel opened, shell ready

300 milliseconds of cryptography, and you have a secure shell on a machine across the world.

Related: SSH cheat sheet · What is SSH? · SSH: Host Key Verification Failed — fix · How HTTPS Keeps Your Data Safe · How Docker Networking Actually Works