How SSH Works
Chapter 1 — How SSH Works
SSH — Secure Shell — is the standard way to connect to a remote machine over a network. It replaced older, insecure protocols like Telnet and rsh by encrypting everything: your commands, the server's responses, and any files transferred. Understanding how SSH works under the hood makes every subsequent chapter easier — and stops you making the mistakes that get people locked out of their own servers.
The Problem SSH Solves
Before SSH, protocols like Telnet sent everything in plain text. Anyone on the same network — a colleague on the same office switch, anyone between you and the server on the internet, or someone with access to router logs — could read your username, password, and every command you typed. SSH eliminates this by encrypting the entire session.
It solves three distinct problems:
- Confidentiality — everything is encrypted; an eavesdropper sees only scrambled bytes.
- Integrity — each message is signed; tampering with it in transit causes the connection to fail.
- Authentication — both sides verify who they're talking to; the server proves it's the right machine, and you prove you're an authorised user.
The SSH Handshake — What Happens When You Connect
When you run ssh user@hostname, a precise sequence of events takes
place before you see a prompt. The whole thing happens in under a second.
~/.ssh/known_hosts.~/.ssh/authorized_keys or the system password database.Public Key Cryptography — the Heart of SSH
SSH uses asymmetric cryptography in two places: verifying the server's identity, and (optionally, but preferably) authenticating the user. The concept is always the same: a mathematically linked key pair where anything encrypted with one key can only be decrypted with the other.
~/.ssh/authorized_keys. Like a padlock — anyone can lock with it, only you can unlock.When you connect with a key pair, the server challenges your client to prove it
holds the private key matching the public key in authorized_keys. The
private key signs a piece of data; the server verifies the signature with your
public key. Your private key is never sent — the server just confirms the maths
works out.
Key Algorithms — Which to Use
| Algorithm | Key file names | Status | Notes |
|---|---|---|---|
| Ed25519 | id_ed25519 / id_ed25519.pub | Use this | Modern elliptic curve. Fast, small keys, very strong. Default recommendation. |
| ECDSA | id_ecdsa / id_ecdsa.pub | Acceptable | Older elliptic curve. Fine but Ed25519 is preferable on all modern systems. |
| RSA (4096-bit) | id_rsa / id_rsa.pub | Still common | Widely supported including older servers. Use 4096-bit if RSA is required. 2048-bit is marginal. |
| DSA | id_dsa / id_dsa.pub | Avoid | Fixed 1024-bit key size. Disabled in modern OpenSSH. Do not generate or use. |
Host Verification — the known_hosts File
Server authentication is the part most people ignore — but it's what protects you from connecting to the wrong machine. The first time you connect to a host, SSH presents the server's public key fingerprint and asks you to verify it:
After typing yes, SSH saves the server's public key to
~/.ssh/known_hosts on your machine. Every subsequent connection
checks this file — if the server presents a different key, SSH refuses the
connection and raises an alarm.
What known_hosts looks like
When the host key changes — a WARNING to take seriously
Removing a stale known_hosts entry
If you know the key changed for a legitimate reason (you reinstalled the server,
for example), remove the old entry with ssh-keygen -R:
Verifying a Fingerprint Before Connecting
The right way to confirm a server's fingerprint on first connection is to check it on the server itself, through a separate channel (physical access, the hosting provider's console, or a colleague who has access). Run this on the server:
Compare this fingerprint character-by-character with what SSH showed you on the
client side. If they match, type yes. If they don't, stop and
investigate.
The SSH Directory — File Roles at a Glance
SSH vs Older Protocols
| Protocol | Encrypted | Still used | Verdict |
|---|---|---|---|
| SSH | Yes — everything | Universally | The correct choice for all remote access |
| Telnet | No — plain text | Legacy embedded systems only | Never use on any network you don't fully control |
| rsh / rlogin | No — plain text | Essentially extinct | Replaced by SSH in the 1990s |
| Mosh | Yes (UDP-based) | Niche | SSH wrapper that handles roaming and intermittent connections — useful on mobile networks |
Key Takeaways
- SSH encrypts everything — credentials, commands, output, and file transfers all travel as ciphertext.
- The handshake happens in two stages — server authentication first (is this the right machine?), then user authentication (are you allowed in?).
- Ed25519 is the key algorithm to use in 2026 — faster and stronger than RSA, supported by all modern SSH implementations.
- known_hosts is your protection against man-in-the-middle attacks — SSH checks it automatically on every connection.
- A changed host key warning demands investigation — verify out-of-band before removing the old entry and reconnecting.
- Your private key never leaves your machine — if asked to copy it to a server, something has gone wrong.