SSH is two things wearing one name: an encrypted pipe to a shell on another computer, and a way to prove that shell should let you in. This walks through both — what you're actually accepting when you click past the fingerprint prompt, why a private key never has to leave your laptop, and the handful of settings that turn a box wide open to the internet into one that mostly isn't. Everything interactive below is a simulation, safe to click.
SSH (Secure Shell) solves two problems that are easy to conflate because one program handles both: it opens an encrypted channel between two machines, and it proves identity before letting anyone use it. Keep them separate in your head — encryption stops eavesdropping, authentication decides who's allowed in — and the rest of the protocol falls into place as "which of these two jobs is this step doing."
The machine you type on is the client. The machine you're connecting to runs an SSH server — a background process listening on a network port, conventionally 22, waiting for connections. "Server" here doesn't imply size or importance; it might be a small always-on machine running nothing but your AI agent, reached exactly the same way a data-center box would be. The relationship is always client asks, server answers — never the reverse in a single connection.
What you get once connected is not a special remote-control interface. It's a real shell — the same program that reads commands and runs them when you sit at that machine's own keyboard — with its input and output routed through the encrypted channel instead of a physical keyboard and screen. SSH doesn't reinvent the shell for the network case; it just gives a shell a longer wire.
SSH is layered. The transport layer negotiates the encryption and verifies the server's host key; the authentication layer runs on top of that encrypted transport to verify the client; the connection layer multiplexes the actual shell (or forwarded ports, or file transfers) as a channel inside the authenticated session. All three run over one TCP connection.
Port 22 is a convention, not a rule. Any port can run an SSH server; 22 is simply the default everyone agrees on so clients don't have to guess.
Everything above happens in a fixed sequence every single time you connect. Step through it below — the left pane is your laptop, the right pane is the server, and the dot between them tracks whether the channel is encrypted yet.
Two moments are worth slowing down on. First, the fingerprint prompt in step 2: the server's host key is just a claim of identity, and on a first connection your client has nothing to check it against, so it shows you a short hash of that key (its fingerprint) and asks you to accept it. What you're actually deciding is narrow — does this key belong to the machine I meant to reach — not some general sense of trusting the server. Say yes once and the answer is cached in ~/.ssh/known_hosts; every future connection compares silently, and if the fingerprint ever changes without you having rebuilt that server, SSH refuses to connect and warns loudly. That warning is the point of the whole exercise: it's the one moment a swapped-out key gets noticed.
Second, step 4 replaces what people picture as a password with a signature. Your client doesn't send anything secret across the wire — it signs data tied to that specific session with your private key, and the server checks the signature against a public key it already has on file. A correct signature is only possible if you hold the matching private key; the server never needed to see it, and an eavesdropper who captures the signature can't extract the key from it or reuse it for a different session.
Key exchange. Modern SSH defaults to an elliptic-curve Diffie-Hellman exchange (curve25519-sha256): both sides compute the same shared secret from public values exchanged in the open, without the secret itself ever crossing the wire. The server signs the exchange transcript with its host private key, which is how the client confirms the key it saw really controls this server, not just that some key was presented.
Not literally a random challenge. The walkthrough says "signs a challenge" for the plain-language version. What the client actually signs (RFC 4252) is data built from the session identifier established during key exchange, plus the authentication request — not a separate nonce the server invents on the spot. The effect is the same: a fresh, session-bound proof that can't be replayed against a different connection.
Password authentication is the version most people meet first: the server holds your password (or a hash of it), your client sends it over the now-encrypted channel, and the server compares. It works, but the secret has to exist in two places and travel every time you connect — which is exactly the shape of thing that leaks in breaches, gets guessed by automated scanners, and gets reused across sites by tired humans. It also authenticates a human who remembers a string, which is a poor fit for a process like an agent orchestrator connecting unattended at 3am.
Key-pair authentication replaces "send the secret" with "prove you have the secret without sending it." A key pair is two mathematically linked files: a private key that never leaves the machine it was generated on, and a public key that's safe to hand out freely — knowing someone's public key gives you no way to impersonate them. You copy the public key onto every server you want to reach; the private key stays put, optionally encrypted at rest by a passphrase you type once per session. Authentication becomes: sign something with the private key, let the server verify the signature against the public key on file. The private key itself is never transmitted, ever — which is precisely why compromising a server you've connected to only exposes a public key that was already public.
ssh-agent so it can hop onward to a third machine as you. Forwarding is convenient, but for as long as the connection is open, anyone with root on the box you forwarded to can ask your agent to sign things elsewhere on your behalf. Fine for infrastructure you fully administer yourself; avoid it on anything you don't.A key's passphrase encrypts the private key file at rest; it plays no role in what any server sees and is never transmitted. It protects you if your laptop's disk is ever read by someone else — without it, anyone who copies the file can use the key immediately.
One command produces a pair:
ssh-keygen -t ed25519 -C "you@example.com" # writes ~/.ssh/id_ed25519 (private) and .pub (public) chmod 600 ~/.ssh/id_ed25519 # sshd refuses to trust a private key with loose permissions ssh-copy-id agent@203.0.113.9 # appends your public key to the server's authorized_keys # or, by hand: cat ~/.ssh/id_ed25519.pub | ssh agent@203.0.113.9 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
-t ed25519 picks the key type: an elliptic-curve algorithm that's become the modern default over older RSA keys because it produces smaller keys, signs faster, and has no known practical weakness at typical sizes. authorized_keys is just a plain-text list on the server, one public key per line — any key listed there is accepted for that account, which is why appending someone's key is the entire "grant access" operation, and deleting a line is the entire "revoke access" operation. Nothing on the server needs to be told about your private key at all; it only ever sees, and only ever needs, the public half.
Once authenticated, what you land in is the same shell model you'd get on your own laptop — the same command syntax, the same idea of a current directory, the same idea of environment variables and a program you just started still running in the background. Nothing about how you type commands changes because a network is involved.
What's different is everything the shell is standing on. It's a different filesystem root, a different set of installed programs, and — this is the one that surprises people the first time — a completely separate process table. Run ps on a server you SSH into and you see that machine's processes, including anything you started on a previous connection and left running. The machine keeps going exactly as it was, whether or not you're currently attached to it; your laptop sleeping or losing wifi has no effect on what's executing over there. That independence is also, as the next section covers, not automatic protection for the specific shell session you're typing into right now.
A machine you log into occasionally is a small, short-lived target. A machine running an agent around the clock is a fixed target with nobody watching it in real time, which changes the math: settings that are merely good practice on a laptop-adjacent server become load-bearing on one. Toggle each setting below and watch what a set of typical automated scan attempts would do to this configuration — the attempts are a fixed, representative sample, not a live feed, but the outcomes are computed from the actual toggle state.
The first three toggles remove specific ways in; the fourth removes bugs before anyone can use them. The network toggle is different in kind from the other three: disabling password auth or root login makes each individual attempt fail; moving off a public port means the attempts never arrive. A private overlay network (often called a tailnet — a VPN-style mesh where only machines you've explicitly added can reach each other) means port 22 simply isn't answering on the public internet at all. Nothing to scan, nothing to guess, nothing to exploit from outside that network. Every other item on this list matters proportionally to how exposed the machine is; removing the exposure is the one change that makes the others matter less.
SSH's job ends at "encrypted, authenticated connection to a shell." It has no opinion about what happens to whatever that shell is running once the connection itself ends. Close the laptop, walk out of wifi range, or let the SSH client crash, and by default the remote shell — and anything it started as a child process, including a long-running agent — receives a hangup signal and exits along with it.
This isn't a bug or an edge case; the connection genuinely ended, and a shell with nothing keeping it alive independently ends when its connection does. Keeping a process running across a dropped connection is a separate job, handled by a persistent terminal session that outlives any one SSH connection to it — you attach, detach, reconnect from a different network entirely, and the process underneath never noticed. That's covered in full in why your agent dies when you close the laptop; SSH gets you to the machine, a persistent session is what keeps you from having to babysit the connection once you're there.
TermRoam boxes ship with the hardening checklist above already applied by default — key-only authentication, no root login, security patches applied automatically — and reachable over a private network rather than a public port. Persistent sessions run underneath every connection, so a dropped SSH session never takes a running agent down with it.