SSH explained: how Secure Shell works

SSH (Secure Shell) is a cryptographic network protocol for operating network services securely over an unsecured network — most commonly for remote login and command-line execution. Instead of sending data as plain text like the protocols it replaced, SSH encrypts everything between client and server, so passwords, commands, and files stay protected from anyone watching the network.

Why SSH exists: the protocols it replaced

In the early 1990s, remote administration relied on protocols that sent everything as plain text: telnet (port 23), rlogin, rsh, and FTP. They provided neither strong authentication nor confidentiality — a password sent over telnet could be read by anyone sniffing the network.

SSH was designed in 1995 by Tatu Ylönen, a researcher at Helsinki University of Technology in Finland, after a password-sniffing attack on his university network. The goal was a protocol with strong authentication and confidentiality, as a replacement for those older tools. Ylönen released his implementation as freeware in July 1995; by the end of that year it had grown to about 20,000 users in fifty countries, and to around 2 million by 2000. In December 1995 he founded SSH Communications Security to develop and market the software.

The protocol has two major versions, SSH-1 and SSH-2, which are not compatible. SSH-2 was standardized by the IETF in January 2006 (RFCs 4250–4256). The most widely used implementation is OpenSSH, forked from the last open-source SSH release by the OpenBSD developers in 1999 and shipped with OpenBSD 2.6.

How SSH works: three protocol layers

RFC 4251 defines SSH as a layered protocol suite with three principal components:

• Transport layer — provides server authentication, confidentiality, and integrity, with perfect forward secrecy.
• User authentication protocol — authenticates the client to the server.
• Connection protocol — multiplexes the encrypted tunnel into multiple logical communication channels.

SSH runs over TCP and defaults to port 22, which the IANA lists as a well-known port. When you run ssh user@server, the SSH client connects to the SSH server daemon (sshd) on that port.

The handshake: version exchange and algorithm negotiation

A connection starts with both sides exchanging identification strings in the form SSH-2.0-softwareversion. Because the protocol defined by the RFC set is version 2.0, the protocol version part is always "2.0" — if you have ever seen SSH-2.0-OpenSSH_9.6 in a log, that is this string. A server that also supports older versions identifies itself as 1.99.

After the version exchange, key exchange begins with each side sending name-lists of the algorithms it supports: key exchange method, host key algorithm, symmetric cipher, message authentication code, and compression. Both sides pick the first algorithm in the client's list that the server also supports, so the negotiated set can differ between implementations.

Key exchange and host authentication

The core of the transport layer is the Diffie-Hellman key exchange. It produces a shared secret that cannot be determined by either party alone; each side derives the same session keys from it, and because fresh random values are generated for the exchange, previously recorded sessions stay protected (forward secrecy).

Diffie-Hellman alone does not tell the client who it is talking to. RFC 4253 combines the exchange with a signature made using the server's host key: the server proves its identity by signing the exchange, which provides explicit host authentication. On a first connection the client has not seen the host key before, so SSH displays the key fingerprint and asks for confirmation. Modern implementations support RSA, ECDSA (RFC 5656), and Ed25519 (RFC 8709) host keys.

Authentication: how the client proves its identity

Once the transport layer is up, the user authentication protocol takes over. RFC 4252 defines several methods — and the only one that is REQUIRED of implementations is publickey:

• Public key authentication — the client proves possession of the private key that matches a public key the server trusts. The secret itself never crosses the network.
• Password authentication — the password travels inside the encrypted tunnel, so it can no longer be sniffed, but it can still be guessed, phished, or reused from a breach elsewhere.
• Keyboard-interactive (RFC 4256) — the server sends one or more prompts; used for one-time passwords and similar schemes.
• Host-based — authentication based on the client machine's identity.

Passwords are convenient, but public-key authentication is the standard recommendation for servers: keys are not reused across sites and cannot be intercepted from the network.

The connection protocol: channels

Everything you do after logging in travels inside the single encrypted tunnel as channels. RFC 4254 defines channels for interactive login sessions, remote command execution, forwarded TCP/IP connections, and forwarded X11 connections. Channels are flow-controlled, and many can be open at the same time — one SSH connection can run a terminal session, a port forward, and an SFTP transfer simultaneously.

Port forwarding (tunneling) is where SSH shines beyond the terminal: you can forward a local port to a service on the remote network, or the other way around, and the traffic rides inside the SSH encryption. This is how encrypted VPNs over SSH (supported by OpenSSH) and SOCKS proxy forwarding work.

What you can do with SSH

• Remote login and administration — SSH clients and sshd are built into Linux, macOS, and BSD systems; Windows ships an OpenSSH port since Windows 10 version 1709.
• File transfer — SCP, SFTP, and rsync over SSH.
• Tunneling — local and remote port forwarding, X11 forwarding, and dynamic forwarding.

SSH security history: what broke and what it means

• SSH-1 (1998) — a CRC-32 integrity weakness allowed content insertion into an encrypted stream; the compensating fixes themselves introduced an integer overflow vulnerability. SSH-1 is considered obsolete — implementations should disable fallback to it.
• SSH-2 (2006) — the IETF standardized SSH-2, adding stronger ciphers such as AES and new key exchange mechanisms; it is incompatible with SSH-1.
• CBC mode (2008) — researchers described a theoretical plaintext-recovery weakness (up to 32 bits) in the then-default CBC cipher mode. Counter (CTR) and AEAD modes such as AES-GCM and ChaCha20-Poly1305 avoid it; modern implementations negotiate them by default.
• Terrapin (2023) — a man-in-the-middle attack against most SSH implementations that downgrades some encryption protections; the practical impact is limited and mostly results in failed connections. The fix landed in OpenSSH 9.6, and both client and server must be upgraded for it to be fully effective.

The practical takeaway: use SSH-2 only, prefer public-key authentication, and keep client and server implementations patched.

SSH vs the protocols it replaced

FAQ

What port does SSH use by default?

Port 22 over TCP, registered as a well-known port by the IANA. The port is configurable on both client and server.

Is SSH the same as TLS or SSL?

No. SSH is a complete protocol suite for secure remote access — transport, authentication, and connection layers — while TLS is a security layer used by protocols like HTTPS. They use similar cryptography but are separate, incompatible protocols.

Are SSH keys safer than passwords?

In most ways, yes. The private key never crosses the network, keys are not reused across websites, and a passphrase-protected key adds another factor. Password authentication remains useful but is only as strong as the password and its reuse habits.

Is SSH safe to use on public Wi-Fi?

For confidentiality, yes — all data is encrypted, so an observer on the same network sees only ciphertext. The one habit to keep: on the first connection, verify the server's host key fingerprint against the value published by the server operator.