Skip to content

How SSH Works

SSH (Secure Shell) is how you get a secure remote shell, copy files (scp/sftp), or tunnel other traffic over an encrypted channel. Under the hood, it does three distinct jobs: encrypt the session, verify the server, and authenticate the client.

1. Establishing an encrypted channel

When you run ssh user@host, the client and server first negotiate:

  • Which encryption, MAC, and key-exchange algorithms they both support
  • A shared session key, derived via a Diffie-Hellman key exchange — both sides compute the same secret without ever sending it over the wire

From this point on, everything — including your password if you use one, and the authentication that follows — travels encrypted with that session key.

2. Verifying the server (host key)

Before trusting the connection, the client checks the server's host key against ~/.ssh/known_hosts. This is what that first-connection prompt is about:

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

If the host key ever changes unexpectedly on a known host, SSH refuses to connect and warns loudly — that's protection against a man-in-the-middle swapping out the server you think you're talking to.

3. Authenticating the client

Two common methods:

Password auth — sent over the already-encrypted channel, checked against the server's user database. Simple, but phishable/brute-forceable and disabled on most production servers.

Public key auth — the one you actually want:

  1. You generate a key pair once: ssh-keygen -t ed25519
  2. The public key goes on the server, in ~/.ssh/authorized_keys
  3. The private key stays on your machine and never leaves it
  4. On connect, the server sends a challenge; your client signs it with the private key
  5. The server verifies that signature against the public key it has on file

Critically, the private key is never transmitted — the server only ever sees proof that you possess it, via the signature.

Why key-based auth is preferred

  • Nothing secret ever crosses the network
  • Keys are effectively unguessable compared to passwords
  • Keys can be scoped (command=, from= restrictions in authorized_keys), rotated, and revoked independently per machine

Beyond a remote shell

Once the encrypted, authenticated channel exists, SSH can carry more than a shell:

  • scp/sftp — file transfer over the same channel
  • ssh -L/-R — local/remote port forwarding, tunneling arbitrary TCP traffic through the SSH connection
  • ssh -D — a SOCKS proxy through the tunnel

All of it rides on the same three building blocks: session encryption, server verification, client authentication.