What is SSH? A plain-language guide to Secure Shell
The encrypted remote-login protocol behind nearly all server administration, your agent's included. Keys vs passwords, how host fingerprints work, and the warnings you'll actually meet.
SSH (Secure Shell) is the protocol that gives you a command line on a computer you can’t physically touch. The standard that defines it calls it “a protocol for secure remote login and other secure network services over an insecure network”: everything you type, and everything that comes back, travels encrypted, normally to TCP port 22 on the remote machine. If you rent a server for an AI agent, SSH is how you’ll administer it: create the server, get an IP address, type ssh user@address, and you’re working inside a machine that might be a thousand miles away.
The protocol, and the program
Two things share the name. SSH the protocol is an open IETF standard, defined across four documents (RFC 4251–4254: architecture, authentication, transport, and connection). SSH the program on nearly every Linux machine is OpenSSH, in its own words “the premier connectivity tool for remote login with the SSH protocol”, developed by the OpenBSD project. It comes in two halves: ssh, the client you run, and sshd, the daemon listening on the server. The obsolete SSH protocol version 1 was deleted from OpenSSH back in 2017 (release 7.6), so everything you will meet today speaks protocol 2.
What happens when you connect
A connection stacks three layers. The transport layer comes first: the server proves its identity with its host key and the two sides agree on encryption, so everything after is private and tamper-evident. Then authentication: you prove who you are. Then the connection layer, which multiplexes the encrypted tunnel into channels: the standard’s own list is “interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections”, all inside one tunnel. That last part is why SSH is more than a terminal: file copies (scp, sftp) and port forwarding ride the same connection.
Keys beat passwords
OpenSSH supports several ways to prove who you are (public-key, password, keyboard-interactive, host-based), and the two you’ll actually meet are keys and passwords. A password is encrypted in transit, but it can be guessed, and on any public server, bots try guesses around the clock. A key pair can’t be guessed at the door: the private key never leaves your machine, the server holds only the public half, and login becomes a cryptographic proof instead of a secret word. That’s why every serious setup guide, ours included, proves keys work, then turns password login off before an agent moves in.
Host keys: the server proves itself too
Authentication runs both directions. The first time you connect to a machine, ssh shows a fingerprint and asks whether to trust it; say yes and the host key lands in ~/.ssh/known_hosts. From then on the client checks the server against that record on every connect. The man page is blunt that if a host’s identification ever changes, ssh warns about it and blocks password authentication to prevent server spoofing. In practice you’ll meet this as the alarming “REMOTE HOST IDENTIFICATION HAS CHANGED” banner. On cloud servers you rebuild, it is usually recycling, not attack. (For scripts, OpenSSH offers StrictHostKeyChecking accept-new: trust new hosts automatically, still refuse changed ones.)
Why agent owners end up caring
An always-on agent needs a computer that stays on, and SSH is the door to that computer: it’s how you install things, read logs, and fix what breaks, from a laptop or from a phone (where mosh papers over flaky connections). It’s also how private things stay private: a dashboard bound to the server’s loopback address can be reached through an SSH tunnel instead of being exposed to the whole internet. One protocol, one open port, everything else closed: that’s the posture the rest of this cluster builds on.