SSH
Secure ShellSSH is the way in. It gives an administrator an encrypted, authenticated channel to a remote machine — a shell, a file transfer, a tunnel — over a network that can’t be trusted. It replaced Telnet and rlogin, which sent passwords in the clear, and is now the backbone of server operations.
SSH proves both ends’ identity, then opens an encrypted channel that can carry a shell, files, or any tunnelled port.
How it works
Encrypt first, verify the server, then authenticate the user — only then does any shell or file traffic flow, and it can all share one connection.
What SSH does, step by step
Over TCP 22, a Diffie-Hellman exchange gives both sides a shared secret without ever sending it.
The client matches the server’s key to known_hosts — that first-connect fingerprint prompt is this check.
A key pair is the norm — the private key stays on the client, its public half sits in authorized_keys.
Run a shell, tunnel a port, or hand off to SFTP — many channels multiplex over the one connection.
In cybersecurity
SSH is the front door to servers, so it is relentlessly probed — and its power to tunnel makes it a favourite for moving quietly once inside.
Disabling password auth stops the endless brute-force attempts against port 22 outright.
Blindly accepting a changed key opens the door to a man-in-the-middle — verify the fingerprint.
Forgotten authorized_keys entries become standing back doors; rotate and audit them.
A compromised jump host can hijack a forwarded agent to reach everything you can — scope it.
The same port forwarding admins love lets an intruder smuggle traffic straight past a firewall.
Short-lived SSH certificates and a single bastion beat scattering static keys across a fleet.