Port 22: SSH — The Secure Shell That Changed Remote Access Forever

Every server you have ever depended on was probably managed through port 22.

Every deployment. Every emergency fix at 3am when the site went down. Every cloud instance that spun up on AWS or Azure or GCP and needed someone to reach inside it. Every router, every firewall, every Raspberry Pi someone SSH'd into from their couch. Port 22 is the door that administrators walk through when no one else can help.

Port 22 carries SSH: the Secure Shell protocol. It is the standard method for secure remote login and command execution over an insecure network. When you type ssh user@server, your client reaches out to port 22 on that machine, and what follows is one of the most important handshakes in modern computing.

The Attack That Started Everything

In early 1995, someone planted a password sniffer on the network backbone of Helsinki University of Technology in Finland.¹ The device sat there quietly, inhaling usernames and passwords as they crossed the wire. Thousands of credentials, captured in plaintext, because every remote access tool of that era (Telnet, rlogin, rsh, FTP) transmitted everything, including passwords, as readable text.

Anyone on the network path could see it all. Every keystroke. Every login. Every command.

Tatu Ylönen was a researcher at the university. Some of the stolen credentials belonged to employees at his company.² He looked at the state of remote access in 1995 and had the reaction that would change the Internet: this is insane.

Password sniffing attacks were among the biggest security problems on the Internet at that time, with new incidents reported almost weekly.³ The tools existed. The encryption math existed. But nobody had built a drop-in replacement for Telnet and FTP that was both secure and simple enough for people to actually use.

Ylönen wrote the first version of SSH in the spring of 1995. He designed it to replace both Telnet (port 23) and FTP (port 21) with a single protocol that encrypted everything from the first byte.⁴

How Port 22 Got Its Number

The story of how SSH claimed port 22 is one of the most charming origin stories in Internet infrastructure.

Ylönen needed a well-known port number, something in the 1-255 range that would give his protocol credibility and allow it to be used in DNS WKS records. He noticed that port 22 was unassigned, sitting right between FTP on port 21 and Telnet on port 23, the two protocols he was replacing.⁵

On July 10, 1995, he emailed IANA (the Internet Assigned Numbers Authority), then managed by the legendary Jon Postel and Joyce K. Reynolds. His email explained that he had written a program to securely log in from one machine to another over an insecure network, that he was already using port 22 in beta testing, and that it would be great if he could keep it.⁶

Joyce Reynolds replied the next day: "We have assigned port number 22 to ssh, with you as the point of contact."⁷

That was it. One email, one reply, one day. On July 12, 1995, at 5:23 PM, Ylönen released SSH 1.0.0 to the world.⁸

By the end of 1995, SSH had 20,000 users across 50 countries.⁹ Today, there are over 20 million publicly exposed SSH servers on the Internet, and the actual count (including machines behind firewalls and on internal networks) is vastly higher.¹⁰

How SSH Works

SSH is elegant because it solves multiple problems in layers. The protocol architecture, formalized in RFC 4251 through RFC 4254, consists of three components stacked on top of each other.¹¹

The Transport Layer (RFC 4253)

This is the foundation. When your SSH client connects to port 22 on a server, the first thing that happens is a version exchange. Both sides announce which version of SSH they speak.¹²

Then comes the key exchange, and this is where the magic happens.

SSH uses Diffie-Hellman key exchange to create a shared secret between client and server without ever transmitting that secret over the wire.¹³ The math works like mixing paint: both sides agree on a base color publicly, each mixes in their own secret color privately, they exchange the results, and each mixes in their secret again. Both arrive at the same final color. An eavesdropper who sees the intermediate results cannot reverse-engineer the secrets, because the mathematical operation (discrete logarithm) is computationally infeasible to reverse.

Modern SSH implementations use elliptic curve Diffie-Hellman (ECDH), which achieves the same result with smaller keys and faster computation.¹⁴ The keypair used is ephemeral: generated fresh for each session and destroyed afterward. This provides forward secrecy, meaning that even if someone steals the server's private key in the future, they cannot decrypt past sessions. You cannot steal something that no longer exists.

During this exchange, the server also proves its identity using its host key. This is why you see "The authenticity of host cannot be established" the first time you connect to a new server. Your client is asking: do you trust this server's fingerprint? Once you say yes, that fingerprint is cached, and any future change triggers a warning. This is SSH protecting you from man-in-the-middle attacks.

The Authentication Layer (RFC 4252)

Once the encrypted tunnel is established, the client must prove who they are. SSH supports multiple authentication methods:¹⁵

Public key authentication is the gold standard. You generate a keypair (public and private), place the public key on the server, and when you connect, the server challenges you to prove you hold the private key without ever transmitting it. This is cryptographic proof of identity. No password crosses the wire. Nothing to sniff.

Password authentication sends your password through the encrypted tunnel. It is secure against network eavesdropping (unlike Telnet), but the server still receives your actual password, which means it is vulnerable to compromised servers and brute-force attacks.

Host-based authentication trusts the client machine itself, similar to the old rsh model but with cryptographic verification.

The Connection Layer (RFC 4254)

This layer multiplexes the encrypted tunnel into multiple logical channels.¹⁶ A single SSH connection can carry an interactive shell session, port forwarding, file transfers via SFTP, and X11 display forwarding simultaneously. Each channel operates independently within the same encrypted pipe.

This multiplexing is one of SSH's quiet superpowers. A single connection to port 22 can do the work that used to require Telnet, FTP, and rsh combined.

The Fork That Saved SSH

Ylönen released SSH 1.0 as freeware, but as the protocol became valuable, the licensing grew restrictive. Each new version of Ylönen's SSH carried more proprietary constraints. By the late 1990s, the most important security tool on the Internet was becoming closed source.¹⁷

In 1999, the OpenBSD project changed everything. Theo de Raadt and his team found the last freely licensed version of SSH (version 1.2.12), forked it through Björn Grönvall's OSSH project, and created OpenSSH.¹⁸ The first release shipped with OpenBSD 2.6 on December 1, 1999.

The OpenBSD team's motivations were exactly what you'd expect from a project obsessed with security: they wanted a freely auditable codebase, free from proprietary restrictions, that could be reviewed by anyone.¹⁹ Markus Friedl then spent months adding SSH protocol version 2 support, and OpenSSH 2.0 shipped with OpenBSD 2.7 in June 2000.²⁰

Damien Miller, Philip Hands, and others quickly ported OpenSSH to Linux and other Unix systems. Today, OpenSSH is the default SSH implementation in Linux, macOS, and (since 2018) Windows.²¹ It is, by an overwhelming margin, the most widely deployed SSH implementation in the world.

Security: The Ongoing Battle

SSH was born from a security crisis, and security has remained its defining concern. The protocol has faced serious challenges over its three decades:

SSH-1 protocol weaknesses. The original SSH-1 protocol had cryptographic vulnerabilities, including a CRC-32 compensation attack that could allow remote code execution.²² This is why SSH-2, with its stronger cryptographic foundations, replaced it entirely.

The Terrapin Attack (2023). Researchers discovered that SSH's binary packet protocol mishandled sequence numbers during the handshake, allowing an attacker to downgrade or disable security features when using ChaCha20-Poly1305 or CBC with Encrypt-then-MAC. Fixed in OpenSSH 9.6.²³

The XZ Utils Backdoor (2024). One of the most sophisticated supply chain attacks in open-source history targeted SSH directly. A compromised contributor inserted a backdoor into the XZ compression library that was linked into sshd on some Linux distributions. The backdoor allowed authentication bypass and remote code execution. It was discovered by a Microsoft engineer who noticed SSH connections were taking 500 milliseconds longer than expected. Half a second saved the Internet.²⁴

regreSSHion (2024). A signal handler race condition in OpenSSH's sshd, scored as a critical remote code execution vulnerability. The cruel irony: it was a regression of a bug originally patched in 2006 (CVE-2006-5051), accidentally reintroduced in 2020. An 18-year-old fix, undone by a code change. It affected glibc-based Linux systems and required approximately 6-8 hours of continuous connection attempts to exploit in laboratory conditions.²⁵

These vulnerabilities are reminders that SSH is not invulnerable. It is, however, continuously defended. The OpenSSH project maintains one of the strongest security track records of any networked software, with vulnerabilities typically patched within days of discovery.

Hardening SSH

The basics of SSH security remain straightforward:

• Disable password authentication. Use public key authentication exclusively.
• Disable root login. Require users to authenticate as themselves, then elevate.
• Use Ed25519 keys. Stronger and faster than RSA.
• Keep OpenSSH updated. The regreSSHion case proves that even old, "fixed" bugs can return.
• Consider changing the default port. Running SSH on a non-standard port reduces automated scanning noise, though it is not a security measure by itself.
• Use fail2ban or similar tools. Rate-limit failed authentication attempts.

The RFCs

SSH's protocol specification was formalized by the IETF in January 2006, authored by Tatu Ylönen and edited by Chris Lonvick:²⁶

Additional RFCs extend the protocol: RFC 4419 defines Diffie-Hellman group exchange, RFC 4716 defines the public key file format, and RFC 8332 added RSA-SHA2 signature algorithms.

Related Ports