---
title: SSH explained: secure remote access, keys, and sessions
description: SSH is how you securely log into and control machines anywhere in the world. Here's what it is, how password vs public-key auth really works, how to run remote commands, and the best clients for every OS.
canonical: https://watchfor.io/blog/ssh-explained
---

# SSH explained: secure remote access, keys, and sessions

2026-06-26 · WatchFor Team · Networking · networking, ssh, security, basics

SSH is how you securely log into and control machines anywhere in the world. Here's what it is, how password vs public-key auth really works, how to run remote commands, and the best clients for every OS.

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](/blog/ftp-ftps-sftp-explained). SSH is the foundation for a surprising amount of infrastructure: remote logins, [SFTP file transfer](/blog/ftp-ftps-sftp-explained), automated deploys, and the tunnels we cover in the [advanced guide](/blog/advanced-ssh-tunnels-jump-hosts).

## Connecting: your first session

The basic command is short:

```
ssh you@server.example.com
```

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](/blog/tls-1-2-vs-1-3) and [mutual TLS](/blog/mtls-explained).

### 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.

1. You copy your **public** key to the server (it lands in `~/.ssh/authorized_keys`).
2. When you connect, the server uses that public key to send a challenge only the matching **private** key can answer.
3. 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](/blog/server-monitoring-basics): 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](/blog/advanced-ssh-tunnels-jump-hosts).
- **Can't connect at all?** Before debugging keys, confirm the server is actually listening — our [port checker](/port-checker) tells you instantly whether [port 22](/blog/what-is-a-network-port) is open or blocked by a [firewall](/blog/what-is-a-firewall).
- **Keep an eye on it.** To catch an outage before you need to log in, point a [TCP monitor](/docs/monitors/network) at port 22 — WatchFor checks it from multiple locations and alerts the second SSH goes unreachable. (It's one of [20+ monitor types](/docs/monitors).)

## 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](/blog/advanced-ssh-tunnels-jump-hosts) opens up the rest of the toolbox.

Related: [Advanced SSH](/blog/advanced-ssh-tunnels-jump-hosts), [FTP vs FTPS vs SFTP](/blog/ftp-ftps-sftp-explained), [TLS 1.2 vs 1.3](/blog/tls-1-2-vs-1-3), [what is a network port](/blog/what-is-a-network-port).

---

Canonical page: https://watchfor.io/blog/ssh-explained · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt