Explain SSH like I'm five

For the average five-year-old:
It's a way to tell computers what to do, even if they're very far away.

For the super genius five-year-old who somehow knows a lot about computers:
It's a protocol for securely connecting to a command line shell (think CMD) on a computer over a network (LAN/Internet/...). You need a server program running on the remote and a client program on your local device. You authenticate with your remote username and either your password or (preferably) your private key (a topic for another ELI5) and are greeted by the same command-line interface as if you were sitting in front of the computer with a keyboard and monitor plugged into it.

So I hear you want to access your Linux/BSD/Unix server, but don't want to be in that data center where it's at. Why don't we do this then?

You remember how HTTPS works, right? Two pairs of keys, a public-private set, on each server and they exchange keys at time of connection, right?

Same deal, but once the connection has encryption, it sets up not a regular request but a set of "channels". One channel is used to control all the others. Another channel is used... for your terminal session on that server.

If you tell SSH to, it can add more channels for more sessions, or use those channels to transfer files (like FTP). It recently can transfer TCP/IP or Ethernet traffic over those channels as well -- an on-demand, ad-hoc VPN.

You can also tell SSH to use a pre-shared set of keys instead of a username and password for those channels. Or ask again for a second password like a Yubikey code.

Where does this all come from? The guys over at OpenBSD, who also make LibreSSL.