Still have port 22 open? Your server's security shouldn't depend on an SSH key

For years, one of the most common recommendations for protecting a Linux server was to use SSH keys instead of passwords. And yes: an SSH key is far more secure than a properly implemented password. But the problem is thinking that a .ssh key by itself makes a server secure.

In 2026, servers exposed to the Internet are under constant automated scanning. Bots sweep entire IP ranges looking for open ports, services, versions, vulnerable configurations and possible entry points. And now there's an additional factor: artificial intelligence. AI can accelerate the analysis of large amounts of information and help identify patterns, weak configurations and potential attack vectors.

That's why the question should no longer be "do I have an SSH key?".

The right question is: how many layers of security does my infrastructure have?

The problem with leaving SSH exposed to the Internet

TCP port 22 is the standard port used by SSH. When a server has port 22 open to the public, anyone can attempt to connect:

Having a properly configured SSH key can prevent an attacker who doesn't hold the key from authenticating. But that doesn't mean it's good practice to keep SSH publicly available to the entire Internet. If nobody needs to access SSH from the Internet, why should it be exposed?

The first layer: close port 22

For a server that only serves a web application, a far more sensible architecture is to allow only the services it actually needs: 80 for HTTP and 443 for HTTPS. Everything else — SSH included — closed to the Internet.

This considerably reduces the exposed surface. But there's an important consideration: closing SSH doesn't mean losing administrative access. It means changing how that access is obtained.

So how do we manage the server?

A far more robust option is to use a VPN to reach the management network. SSH can keep working, but it's not publicly available on the Internet: the server accepts SSH only from the private management network.

And if I need to serve a web application?

Then we typically need to expose port 80 (HTTP) — in many scenarios only to redirect traffic to HTTPS or for validation processes — and port 443 (HTTPS), which is the port that really matters for a modern web application.

And the database should not be directly exposed to the Internet. Ever.

Second layer: firewall

Closing port 22 doesn't help much if we then leave dozens of services we don't need open. The firewall should follow a simple rule: deny by default and allow only what's necessary.

The exact ports and rules will depend on your architecture, but the principle is the same: don't expose a service just because it's installed.

Third layer: Cloudflare

If you want to take the architecture one step further, you can place services like Cloudflare in front of your infrastructure. Cloudflare can act as an additional layer between the Internet and your server, providing CDN, protection against certain kinds of malicious traffic, WAF and other security capabilities.

Security is not about hiding port 22

Moving SSH from port 22 to 2222, 2200 or any other may reduce some automated scans that target the standard port. But a scanner can discover ports. Changing the port must not be confused with protecting the server: it's a secondary measure.

Your architecture should be concerned with the fundamental questions:

• Which ports are exposed and which services are listening?
• Who can get access, and from where?
• What permissions does each user have?
• What happens if a credential is compromised?
• Are there monitoring and logs? How is an intrusion detected?
• How is access revoked, and how is the server recovered?

An SSH key is not a fortress wall

An SSH key is an excellent authentication tool. But if your architecture is Internet → port 22 → SSH → server, the only major barrier between the Internet and administrative access ends up being SSH authentication. Compare that with a layered architecture:

The difference is enormous. That is defense in depth.

The AI era changes the game

Information security has always been a problem. But AI is changing the speed at which certain tasks can be performed. Attackers can automate more and more of the process:

1. 1Discover assets
2. 2Identify services
3. 3Analyze responses
4. 4Correlate information
5. 5Look for vulnerable configurations
6. 6Prioritize targets
7. 7Automate certain actions

That's why it's no longer enough to think "I have a strong password", "I have an SSH key" or "I changed port 22". Security must be approached as a system of layers.

Basic security checklist for a VPS

Before putting a server into production, at a minimum you should review:

Network

• Firewall enabled with a deny-by-default policy
• Port 22 closed to the public whenever it's not needed
• Only 80/443 exposed when it's a web server
• Databases with no public exposure
• Internal services restricted

SSH

• Password authentication disabled; key-based access
• Direct root access disabled
• Individual users with least privilege
• Administrative access over VPN whenever possible

Application

• HTTPS mandatory
• Secrets out of the code
• Dependencies up to date
• Logging enabled and proper session and authentication management

Infrastructure

• Operating system, Docker and components up to date
• Backups, monitoring and alerts
• Recovery plan

External layer

• DNS properly configured
• WAF when needed
• DDoS protection according to your risk level
• CDN / reverse proxy when it adds value

The right question

Don't ask "how do I hide my SSH port?". Ask "why does my server need to be exposed to the Internet?". If the answer is only "because I need to manage it", then there's probably a better architecture: close SSH to the public Internet, keep only the services you need — for example 80 and 443 for a web application — and use a private network or VPN for administration. And if the project requires it, add layers like Cloudflare, WAF, monitoring, segmentation and access controls.

Because in cybersecurity there is no single magic configuration. A .ssh key won't save you from an insecure architecture. Real security lives in the layers: less exposed surface, more control, more visibility, more layers of defense.