SSH: Secure Shell

What SSH is

SSH (Secure Shell), defined in RFC 4251, secures interactive remote administration, command execution, and file transfer over TCP — it's the direct, encrypted replacement for older cleartext protocols like Telnet, rlogin, and FTP, all of which sent commands, output, and credentials in the open. SSH's architecture is layered into three protocols working together: a transport layer (RFC 4253) that handles encryption, integrity, and server authentication; an authentication layer (RFC 4252) that verifies the connecting user; and a connection layer (RFC 4254) that multiplexes everything the session actually does — a shell, file transfer, port forwarding — over that one secured connection.

The SSH transport layer

Before any authentication happens, the transport layer runs a key exchange — the same Diffie-Hellman primitive from the fundamentals lesson — to derive session keys for encryption and integrity, so everything from this point forward, including the authentication step itself, is encrypted. As part of this exchange, the server presents a host key, proving it is the same server the client has connected to before (or establishing that identity for the first time) — this is SSH's equivalent of TLS's server certificate, but, as the later section on trust-on-first-use covers, verified very differently.

SSH authentication methods

SSH supports several authentication methods, but two matter most in practice. Password authentication sends a password over the already-encrypted connection — safe from eavesdropping in transit, but still vulnerable to brute-forcing, credential reuse, and phishing, since the secret itself can be guessed, stolen, or typed into a fake prompt. Public-key authentication is preferred instead: the server stores only the user's public key (typically in authorized_keys), and the client proves it holds the matching private key — which never leaves the client's machine — by signing a value the server provides. There is no shared secret to brute-force or phish, because nothing secret ever crosses the network at all.

The SSH connection protocol and channels

Once authenticated, a single SSH connection doesn't have to carry just one thing. The connection protocol multiplexes multiple logical channels over that one encrypted TCP connection: an interactive shell, a single command execution, an SFTP file transfer, and port-forwarded traffic can all run concurrently, each in its own channel, without opening a second TCP connection or repeating the handshake and authentication for each one.

Interactive SSH key authentication

Step through a complete SSH connection: the host-key check, the key exchange that encrypts everything that follows, and public-key authentication — where the client proves it holds a private key without ever sending it, by signing a challenge the server provides.

Host-key verification and trust-on-first-use

SSH doesn't rely on certificate authorities the way TLS does by default — it uses trust-on-first-use (TOFU). The first time a client connects to a server, it has no way to independently verify the host key, so it prompts the user to accept it and stores it locally in known_hosts. Every later connection then checks the server's host key against that stored value: a match means the client is still talking to the same server; a mismatch produces a loud warning, because it means either the server's key legitimately changed (a reinstall or key rotation) or a man-in-the-middle is now presenting a different key. TOFU's real weakness is exactly that first connection — it trusts blindly once, which is why the Pro deep dive covers SSH certificates as the way to remove that blind spot at scale.

Inspect SSH evidence

ssh -v user@host prints the full handshake to the terminal: the negotiated key exchange and host-key algorithms, the host-key fingerprint being checked against known_hosts, and which authentication methods were offered and accepted. ssh-keygen -lf ~/.ssh/known_hosts lists the fingerprints SSH has already trusted for past connections, which is exactly what a client compares a server's host key against on every new connection.

Guided SSH key practice

Work through why public-key authentication specifically defeats phishing, not just brute-forcing. With password authentication, an attacker who tricks a user into typing their password into a fake prompt now has the actual secret, and can use it to authenticate anywhere that password is valid. With public-key authentication, the server sends a different random challenge on every single connection attempt, and the client's response (a signature over that challenge) is only valid for that one exchange — capturing a signed response from a previous login doesn't let an attacker authenticate again, because the next challenge will be different. There is simply no reusable secret for a phishing page to capture.

Troubleshoot SSH

1. Check private key file permissions first: SSH clients refuse to use a private key file that is readable by other users on the system (commonly reported as "Permissions 0644 for 'id_rsa' are too open").
2. A "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" message means the server's host key no longer matches what's stored in known_hosts — treat this as a possible man-in-the-middle until you've verified the change out-of-band (for example, confirming with the server's administrator that it was rebuilt or re-keyed).
3. If the wrong identity is offered during authentication, confirm which private key the client is actually using (-i to specify one explicitly, or check what's loaded in ssh-agent) rather than assuming the default key is the one on the server's authorized_keys.
4. Rule out a network-layer problem (firewall blocking TCP 22, or the server listening on a nonstandard port) before assuming the issue is cryptographic — a connection that never completes the TCP handshake isn't an SSH problem at all.
5. An "no matching key exchange method found" (or similar algorithm-negotiation) error means the client and server share no common algorithm — often a hardened modern client refusing to use a legacy server's outdated options, or vice versa.
6. On the server, confirm authorized_keys and the .ssh directory have the expected ownership and restrictive permissions — SSH servers, like clients, often silently ignore a key file whose permissions are too permissive.

Knowledge check and summary

Pro deep dive