What is port 22 used for?
Port 22 is the standard TCP port for SSH (Secure Shell), the encrypted protocol used to manage a server remotely from the command line. SFTP and SCP also run over it to transfer files securely. It exists for administration, not for the whole Internet: the recommended setup is to close it publicly and reach it over a VPN.
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:
The entire Internet reaches your SSH — the key is the only barrier.
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.
Deny by default: port 22 and internal services die at the firewall.
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.
SSH still works — but it no longer exists for the Internet.
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.
Every hop is a layer with its own rules.
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.
| Port | Service | Internet |
|---|---|---|
| 22 | SSH | ❌ Closed |
| 80 | HTTP | ✅ Open |
| 443 | HTTPS | ✅ Open |
| 5432 | PostgreSQL | ❌ Closed |
| 3306 | MySQL | ❌ Closed |
| 8000 | Internal API | ❌ Closed |
| Others | Internal services | ❌ Closed |
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:
Defense in depth: each layer can stop what the previous one let through.
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:
- 1Discover assets
- 2Identify services
- 3Analyze responses
- 4Correlate information
- 5Look for vulnerable configurations
- 6Prioritize targets
- 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
If your infrastructure runs on AWS, the next step is reviewing the whole account, not just the server: how exposed is your AWS infrastructure?
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.