SSH Explained: The Secure Shell That Quietly Runs the Internet

SSH lets you safely control a remote computer over the open internet — encrypting every keystroke, every command, every response. Before it existed, logging in remotely meant broadcasting your password in plain text for anyone to read.

The Problem: Everything Was Plaintext

In the early 1990s, the standard tools for remote access — Telnet, rlogin, FTP — sent data in plaintext. Your username and password traveled across the network as readable text. Anyone with a packet sniffer on the same network could read them instantly.

A Brief Origin Story

In early 1995, a password sniffer was planted on the network backbone of Helsinki University of Technology. It quietly harvested thousands of credentials — including those of a company run by researcher Tatu Ylönen. His response: write something better. By July 1995, SSH-1 was released as free software. Within six months, an estimated 20,000 users in 50 countries had adopted it.

Ylönen chose port 22 deliberately — it sits neatly between Telnet (port 23) and FTP (port 21), the two protocols it was meant to replace. In 1999 the OpenBSD team forked the codebase and released OpenSSH, the open-source implementation that ships with virtually every Linux, macOS, and modern Windows system today.

How SSH Secures the Connection

SSH uses two kinds of cryptography, each playing a different role. The first is asymmetric encryption — better known as public-key cryptography — and it is the heart of what makes SSH both secure and convenient. The second is symmetric encryption, used to make the actual session fast once the connection is established.

Let's start with the one that's hardest to picture.

The Padlock Analogy: Public and Private Keys

Forget computers for a second. Imagine you want someone to be able to send you a secret message, but you don't want to share a secret password with them in advance.

You could send them an open padlock — unlocked, no key needed to close it. Anyone can put a message in a box, snap the padlock shut, and send it to you. But only you can open it, because only you hold the key. You can hand out thousands of open padlocks. None of that puts your key at risk.

This is exactly how SSH public-key authentication works. When you connect, the server holds your public key in ~/.ssh/authorized_keys. It sends you a challenge encrypted with that key — a puzzle only your private key can answer. If you answer correctly, you're in. Your private key never left your machine.

Compare that to a password: the password has to travel to the server to be checked, even if it does so inside the encrypted channel. A key-pair challenge never exposes the secret at all.

So Why Are There Two Kinds of Encryption?

Public-key cryptography is secure — but slow. Encrypting an entire interactive session with it would be computationally painful. So SSH uses it only at the start: to verify identities and securely agree on a shared key that neither side ever transmitted over the network.

After that handshake, SSH switches to symmetric encryption (like AES), where both sides use the same key. Symmetric encryption is fast enough to handle every keystroke in real time. The trick is that this shared key was derived from the public-key exchange — so anyone intercepting the connection cannot reconstruct it.

Your First SSH Connection

Before typing any command, two things need to be true simultaneously — one on your machine, one on the server. If either is missing, the connection won't reach the other side.

A quick note on that last requirement. When you run ssh alice@198.51.100.10, the username alice must exist as a real system account on the remote machine — created with adduser or equivalent. SSH doesn't create users; it just lets existing ones authenticate. Most cloud providers (Hetzner, DigitalOcean, AWS) create a default user for you when they provision the server — typically debian, ubuntu, or root depending on the distro. If you try to log in as a user that doesn't exist, the server simply refuses the connection, usually with a Permission denied error that looks identical to a wrong password.

The most common cause of a failed first connection is the firewall — the server is running sshd just fine, but port 22 is blocked and the connection silently times out. If that happens, check your firewall rules before anything else.

The client ships by default on Linux, macOS, and Windows 10+. Start by confirming it's there:

To connect to a remote machine, the pattern is always ssh username@address. The client will connect to port 22 by default:

The first time you connect to a server you have never reached before, SSH pauses and shows something like this:

What Is That Fingerprint?

Every SSH server has its own identity — a unique key pair that was generated when sshd was first installed. The host key fingerprint is a short, human-readable hash of that public key. Think of it like a passport photo for the server: a compact representation that's easy to compare but impossible to fake.

The line ED25519 key fingerprint is SHA256:d029f87e... is SSH showing you that passport photo and asking: "Is this the server you intended to connect to?" The problem is that on a first connection, your client has never met this server before — it has nothing to compare against. That's the window of risk. If someone had intercepted your connection and was impersonating the server (a man-in-the-middle attack), they would present their own key, and you would have no way of knowing unless you check.

Once you type yes and accept it, SSH saves the fingerprint in ~/.ssh/known_hosts on your machine. From that point on, every time you connect to that server, SSH silently checks that the fingerprint still matches. If it ever changes — the server was rebuilt, the key was rotated, or something more sinister — SSH will refuse to connect and show a loud warning instead of a silent login.

This warning means: "the server at this address is presenting a different identity than last time." It could be innocent — the server was reinstalled and got a new key — or it could be an attack. Either way, do not ignore it. Investigate before proceeding.

How to Actually Verify the Fingerprint

Typing yes blindly defeats the entire purpose. The right approach is to compare the fingerprint SSH shows you against a copy you obtained through a separate, trusted channel. In practice this means one of three things:

On every subsequent connection, the warning is gone. SSH recognises the server and goes straight to the password prompt — or, if you have set up public-key authentication, logs you in automatically:

Password vs. Public-Key: Which to Use

Password authentication is fine to start with. But any server on the public internet will attract automated login attempts within hours of going live. Public-key authentication makes those attacks pointless — there is no password to guess.

Turning On Key-Based Login

Key-based authentication has a small chicken-and-egg quirk. The server can only recognise your key once your public key is sitting in its ~/.ssh/authorized_keys file — but putting it there usually requires logging in first. So the very first connection is done the ordinary way, with a username and password, precisely because the server doesn't have your public key yet. That password login is the bootstrap; everything after it can be keys.

Once you're in, the goal is to get your public key onto the server. Only the public half ever travels — the private key stays on your laptop, exactly as it did during the challenge you saw earlier. You could do this by hand, appending the contents of your .pub file to the right authorized_keys and fixing the file permissions, but there's a purpose-built tool that handles the whole thing in one step:

The tool is ssh-copy-id. You run it from your own machine, pointing it at the same user and server you'd normally log in to:

If you have more than one SSH key on your machine and want to be explicit about which one gets installed, add the -i flag pointing at the specific public key you want to copy:

Without -i, ssh-copy-id picks up whatever default keys it finds in ~/.ssh/, which may not be the one you meant. The .pub extension is what you want here — you are copying the public half, never the private one.

Under the hood, ssh-copy-id simply opens an ordinary SSH connection — which is why it asks for your password once more — so the entire transfer of the key is encrypted like any other SSH traffic. It then appends your public key to ~/.ssh/authorized_keys for the user you named, and quietly fixes the file and directory permissions, which sshd is strict about. From that point on, logging in is passwordless:

One rule sits underneath all of this: only the public key is ever distributed. The private key never gets copied to the server, and never to another laptop or workstation either — the moment a private key lands somewhere it doesn't belong, it stops being private. If you work from more than one machine, each one gets its own key pair, and each public key gets added to the server.

One More Layer: The Passphrase

Public-key authentication solves the brute-force problem — but it introduces a new one. Your private key is a file sitting on disk. If someone steals your laptop, copies that file, and there's no password protecting it, they now have everything they need to log in to every server that trusts that key. No cracking required.

That's what the passphrase is for. When you generate a key pair, SSH asks if you want to encrypt the private key file with a passphrase. If you set one, the file on disk is encrypted — it's useless to anyone who doesn't also know the passphrase. You only type it on your own machine to unlock the key; it never travels to the server.

In practice, when you connect with a passphrase-protected key, SSH asks for it locally before using the key:

That prompt appears on your machine, not on the server. The passphrase decrypts the key locally, and then the key does the rest. The server only sees the cryptographic proof — never the passphrase, never the raw private key.

If typing the passphrase on every connection becomes inconvenient, ssh-agent can hold the unlocked key in memory for the duration of your session — you unlock it once and it stays ready until you log out. That's a topic for a future article.