SSH explained: secure remote access, keys, and sessions

There's a moment in every developer's life when a server stops being an abstraction and becomes a thing you have to talk to. Maybe a site is down at 2am, maybe a deploy went sideways. You open a terminal, type a short incantation — ssh you@server — and suddenly you're standing inside a machine that might be on another continent, typing commands as if it were on your desk. That's SSH, and once it clicks, it's one of the most empowering tools you'll ever learn.

What SSH actually is

SSH (Secure Shell) is a protocol for securely operating a remote computer over an untrusted network. It does two things at once:

Encryption — everything between you and the server is scrambled, so no one in between can read your commands, passwords, or output.
Authentication — it proves you are who you say you are (and proves the server is the real server, not an impostor).

It runs on port 22 by default and replaced older tools like Telnet, which sent everything — including passwords — in cleartext. SSH is the foundation for a surprising amount of infrastructure: remote logins, SFTP file transfer, automated deploys, and the tunnels we cover in the advanced guide.

Connecting: your first session

The basic command is short:

ssh [email protected]

The first time you connect, SSH shows the server's host key fingerprint and asks if you trust it. Say yes, and that fingerprint is remembered (in a file called known_hosts). If it ever changes unexpectedly later, SSH loudly refuses to connect — that's a feature, protecting you from someone impersonating the server.

After that, you authenticate, and you're dropped into a shell on the remote machine. Everything you type runs there, not on your laptop.

Passwords vs keys — use keys

There are two ways to prove who you are. One is fine; the other is much better.

	Password auth	Public-key auth
How	Type the account password	Prove you hold a private key
Secret sent over the wire?	The password is verified each login	Nothing secret ever leaves your machine
Brute-forceable?	Yes — bots hammer port 22 all day	Practically no
Convenience	Type it every time	Automatic, no typing
Best for	A quick one-off	Everything real

Password login works, but it's the thing automated attackers spend all day guessing. Key-based authentication is both safer and more convenient once set up. It's the same public/private-key idea behind TLS and mutual TLS.

How key auth works (the quiet magic)

You generate a key pair with ssh-keygen: a private key that never leaves your computer, and a public key you can hand out freely.

You copy your public key to the server (it lands in ~/.ssh/authorized_keys).
When you connect, the server uses that public key to send a challenge only the matching private key can answer.
Your client answers it locally — the private key itself is never transmitted.

The result: you log in with no password typed and no secret ever crossing the network. Lose the laptop? Remove that one public key from the server. It's the rare upgrade that's more secure and less effort.

Running commands without "logging in"

Here's the trick that turns SSH from a login tool into an automation superpower. You don't have to start an interactive session at all — append a command and SSH runs it, returns the output, and disconnects:

ssh you@server 'uptime'

14:02:51 up 42 days,  load average: 0.08, 0.03, 0.01

That single line is the backbone of countless scripts and deploy tools: check disk space across ten servers, restart a service, tail a log — all without ever "entering" the machine. Combine it with key auth and it runs unattended, no password prompt. It pairs naturally with server monitoring: your monitoring tells you what's wrong, and a quick ssh ... 'command' lets you look closer.

Clients for every OS

OS	What to use
Linux	Built in — just `ssh` in any terminal
macOS	Built in — `ssh` in Terminal or iTerm
Windows	Built-in OpenSSH (`ssh` in PowerShell/Terminal), or PuTTY
Mobile/other	Termius, Blink (iOS), JuiceSSH (Android)

On Linux and macOS, SSH has been built in for years. Modern Windows ships OpenSSH too, so ssh you@server works in PowerShell without installing anything — though many people still like PuTTY.

A few tips that save real pain

Set up keys on day one. Run ssh-keygen, copy the public key with ssh-copy-id you@server, and never type a server password again.
Disable password login on servers once keys work — it removes the entire brute-force attack surface.
Use an SSH config file. Aliases like ssh prod instead of long host strings are covered in the advanced guide.
Can't connect at all? Before debugging keys, confirm the server is actually listening — our port checker tells you instantly whether port 22 is open or blocked by a firewall.
Keep an eye on it. To catch an outage before you need to log in, point a TCP monitor at port 22 — WatchFor checks it from multiple locations and alerts the second SSH goes unreachable. (It's one of 20+ monitor types.)

The bottom line

	In one line
What	Encrypted, authenticated remote control over port 22.
Auth	Use keys, not passwords — safer and zero typing.
Key magic	The private key never leaves your machine.
Power move	`ssh you@server 'command'` runs remotely with no login.

SSH turns any server on earth into something you can safely reach, inspect, and control from a single terminal line. Learn key-based auth, get comfortable running one-off remote commands, and you've got the essentials. When you're ready for jump hosts, tunnels, and SOCKS proxies, the advanced SSH guide opens up the rest of the toolbox.