Secure Shell

In short: SSH — an encrypted protocol for securely logging into a remote machine’s command line over a network.

In more detail: Replaces older, unencrypted protocols like Telnet. Authentication happens via password or — more common and more secure — via a key pair (public/private key). Besides pure remote login, SSH is also used for file transfer (SCP, SFTP) and tunnelling other connections.

In Depth

ssh-keygen -t ed25519          # generate a key pair
ssh-copy-id user@server         # copy the public key to the server
ssh user@server                 # connect without entering a password

The main security gain over older protocols like Telnet is that the entire connection is encrypted from the start — with Telnet, passwords and the complete session history were transmitted in plain text, readable with simple network sniffing tools. SSH first establishes an encrypted channel via a key exchange, before any login credentials are transmitted at all (see SSH-TRANS).

Key-based authentication is considered considerably more secure than passwords: the private key never leaves your own device, the server only knows the matching public key and can use it to check whether the client possesses the corresponding private key, without it ever being transmitted — more resistant to brute-force attacks and password leaks than classic password logins. In server environments, password login via SSH is therefore often disabled entirely, so only key authentication remains possible.

SSH agent and key management

Anyone using several SSH keys for different servers or services (e.g. GitHub, private servers, employer infrastructure) usually uses an SSH agent — a background process that keeps decrypted private keys in memory, so you only have to enter a key’s password/passphrase once per session, instead of again for every single SSH connection. The agent automatically hands the matching key to SSH when needed, without the private key itself ever leaving the agent’s secure environment.

Known host keys and man-in-the-middle protection

On the very first connection to a new server, SSH shows a “fingerprint” of the server key and asks whether it’s trustworthy — this fingerprint is then stored locally in the known_hosts file. On every following connection, the client compares the presented server key with the stored fingerprint; if it differs, SSH loudly warns of a possible man-in-the-middle attack (someone may have inserted themselves between the client and the real server) and, by default, refuses the connection until the user explicitly removes the old entry. This warning should never simply be ignored, unless you’re sure the server key has changed legitimately (e.g. after reinstalling the server).

Port forwarding and tunnelling

Beyond pure terminal access, SSH also allows any TCP connection to be securely routed through the existing encrypted channel (port forwarding/tunnelling) — practical for, say, accessing a database only reachable within a private network, without having to make that database directly reachable from the internet itself. ssh -L 5432:localhost:5432 user@server, for example, forwards local port 5432 through the SSH connection to the remote database port.

See also: Shell, SSH, Private Key