DEV Community

loading...

Explain SSH like I'm five

Saurabh Sharma
Web development React.js GraphQL Typescript JavaScript Design SEO
・1 min read

Discussion (2)

Collapse
franga2000 profile image
Miha Frangež • Edited

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.

Collapse
strredwolf profile image
STrRedWolf

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.