Port 22: SSH (Secure Shell)

Port 22 is where you knock when you need to speak privately with a machine across the Internet.

As the default port for SSH (Secure Shell), it's the gateway to remote administration—the way system administrators, developers, and DevOps teams securely manage servers, transfer files, and tunnel through hostile networks. If you've ever typed a command on a server you couldn't physically touch, SSH made that possible.

The Problem SSH Solved

Before SSH, remote access was terrifying if you understood what was happening.

Telnet let you log into remote systems. FTP let you transfer files. Both were revolutionary—and both transmitted everything in plaintext. Every keystroke. Every password. Every file. Anyone on the network path between you and the server could see everything.

In early 1995, someone planted a password sniffer on the network backbone at Helsinki University of Technology in Finland. Not malware—actual hardware, quietly recording thousands of usernames and passwords as they crossed the network in cleartext. Some of those credentials belonged to employees of a company run by Tatu Ylönen, a researcher at the university.

Ylönen's response was SSH: a protocol that encrypts the entire conversation between client and server. Three months of cryptography and network programming later, SSH 1.0 was ready. The network becomes blind to your secrets. Passwords, commands, file contents—all wrapped in cryptography that makes eavesdropping worthless.

Why Port 22?

The day before announcing SSH 1.0 in July 1995, Ylönen emailed IANA requesting a port number. He asked for port 22 specifically—it was unassigned and sat between Telnet (port 23) and FTP (port 21), the two protocols SSH was designed to replace. The next day, Joyce Reynolds wrote back: "We have assigned port number 22 to ssh."¹

That was how the Internet worked then. One email to the right people, and you got a port number. By the end of 1995, SSH had 20,000 users in fifty countries. By 2000, two million.

What Happens on Port 22

When you type ssh user@server.com, your client reaches out to port 22 on that server. An SSH daemon (the server-side software) is listening. They negotiate encryption, verify each other's identity, and establish a secure channel. From that moment, everything between you and the server is encrypted.

What can you do through that channel?

Remote command execution: Log in and type commands as if you were sitting at the server's keyboard. This is how most servers are managed—headless machines in data centers, with no monitor or keyboard attached, responding to SSH commands from across the world.

File transfer: SCP and SFTP use SSH's encryption to move files securely. The insecure FTP protocol should have died decades ago; SSH gave us the replacement.

Tunneling: SSH can forward traffic from one port to another, creating encrypted passages through the network. Need to access a database that only accepts local connections? Tunnel through SSH. Need to route traffic through an intermediate server? SSH can do that. It's a VPN you can create with a single command.

Port 22 Is Under Constant Attack

Here's an uncomfortable truth: if you expose port 22 to the Internet, you will be attacked. Not might be. Will be.

Automated bots scan the entire Internet looking for open SSH ports. When they find one, they start guessing passwords. Common usernames, common passwords, dictionary attacks—thousands of attempts per hour, every hour, forever. Check your SSH logs on any public server and you'll see the evidence: failed login attempts from IP addresses around the world.

This is why security on port 22 matters more than almost anywhere else.

The Security That Actually Works

Key-based authentication: Instead of a password, SSH can authenticate using cryptographic key pairs. You keep the private key on your machine; the server holds the public key. When connecting, you prove you possess the private key without ever transmitting it. No password to guess. No brute force attack possible. This is the single most important security improvement you can make.

Disable password authentication entirely: Once key-based auth works, turn off password auth. Now those automated bots are guessing at a door that doesn't exist.

Disable root login: Don't let anyone SSH directly as root. Log in as a regular user, then elevate privileges with sudo. Better audit trails, smaller attack surface.

Keep SSH updated: OpenSSH has an excellent security record, but vulnerabilities appear occasionally. Update your SSH software like you update everything else that faces the Internet.

The Port-Changing Debate

A common recommendation: move SSH from port 22 to something obscure, like 2222 or 22222. The theory is that automated attacks target port 22, so hiding on a different port reduces the noise.

This is "security through obscurity," and opinions are strong.

The critics are right that it's not real security. Port scanning will find SSH wherever you hide it. A determined attacker won't be fooled.

But the proponents have a point too: most attacks aren't determined. They're automated scripts hitting port 22 on every IP address they can find. Moving to an alternate port genuinely does reduce attack volume by 99%. Your logs get quieter. Your server wastes less CPU rejecting garbage connections.

Think of it like hiding your house key under a different rock. It won't stop a burglar who's targeting you specifically. But it will stop the lazy opportunist who only checks the obvious spots.

Never treat a port change as a substitute for real security. But as one layer among many? It has legitimate value.

SSH in the Modern World

Cloud infrastructure runs on SSH. When you spin up a server on AWS, Azure, or Google Cloud, how do you access it? SSH keys. Configuration management tools like Ansible connect to servers via SSH. Developers push code through Git over SSH. Containers might be replacing some traditional server management, but SSH remains the universal fallback—the way you get into a machine when everything else fails.

Some organizations are moving toward browser-based consoles and API-driven access for production systems, reducing direct SSH exposure. These approaches have merit for specific use cases. But for the foreseeable future, SSH on port 22 remains the foundation of remote server access.

Why This Matters

Port 22 represents something important: the ability to work securely across untrusted networks.

Before SSH, remote administration required trusting everyone between you and your server. That trust was misplaced—networks are full of listeners. SSH removed the need for that trust by making the conversation private.

Thirty years later, the protocol remains essential. The encryption has gotten stronger, the implementations more refined, but the core promise is unchanged: you can manage a machine on the other side of the world, and no one listening in the middle will understand a word.

Sources