Is it safe to have port 22 open to the internet?

It can be, for a server you manage remotely, if SSH only accepts key-based logins, root login is disabled and OpenSSH is up to date. With password logins allowed, it is a constant target for automated password guessing. Restricting it to known IP addresses or a VPN is safer still.

Should I change the SSH port from 22?

Moving SSH to another port cuts down log noise from bots, but it is not a security fix. Scanners find SSH on any port in seconds. Key-only logins and an IP allowlist are what actually protect it.

How do I check if my SSH server allows password logins?

From another machine, run nmap -p 22 --script ssh-auth-methods your-server. If the output lists password or keyboard-interactive, password logins are allowed. Only publickey means keys only.

Low risk Port 22 · SSH

SSH port 22 is open: is it a risk, and how to secure it

By Stephane Meus, CEH, PenTest+ · Updated 17 October 2026 · 6 minute read

Short answer: port 22 is SSH, the standard way to log in to Linux servers, NAS boxes and network gear remotely. On a server you manage over the internet, having it open is normal. What makes it risky is how it's set up: password logins, root allowed to log in, or an outdated OpenSSH.

The fix: allow key-based logins only, turn off root login, keep OpenSSH updated, and limit who can reach the port. If nobody uses SSH on that machine, close it.

What is port 22?

SSH (Secure Shell) gives an administrator a command line on a remote machine, encrypted end to end. Web hosts, cloud servers (AWS, Azure, DigitalOcean and others) and most Linux systems have it on by default. It also shows up on NAS devices, routers and firewalls, sometimes switched on without anyone remembering.

Unlike Telnet or FTP, SSH encrypts everything, so the finding is not about eavesdropping. It's about who can try to log in, and how hard that is.

Why it still matters

Bots try passwords all day. Any SSH server on the internet sees a steady stream of automated login attempts with common usernames like root, admin and ubuntu. With password logins allowed, one weak or reused password is enough.
Root login is a shortcut for attackers. If root can log in directly, a guessed password gives full control of the machine immediately.
Old OpenSSH versions have serious flaws. For example, CVE-2024-6387 ("regreSSHion") let attackers run code on unpatched Linux servers running OpenSSH 8.5p1 to 9.7p1 without logging in. It was fixed in 9.8p1, and most Linux distributions shipped patches.
Forgotten devices. A NAS or router with SSH on and the default password is a common way in.

How it looks in your report your-server

22 SSH Normal, but should be key-based and rate-limited Low

If the scan detects an outdated OpenSSH, that is reported separately

How to check your SSH setup

See what's answering. A FreshScanSentry Basic Scan shows port 22 and the SSH version. Or, from a machine outside your network:
```
nmap -p 22 -sV your-server
```
Check whether passwords are accepted:
```
nmap -p 22 --script ssh-auth-methods your-server
```
If the result lists password or keyboard-interactive, password logins are allowed. Only publickey means keys only, which is what you want.
Check the version. On the server, run ssh -V. Then check your distribution's security notices: Ubuntu and Debian often fix vulnerabilities without changing the version number. The outdated OpenSSH guide explains how.

Only scan servers you own or have written permission to test.

How to secure it

Keep your current SSH session open while you make these changes, and test a new login from a second window before closing it. That way a mistake can't lock you out.

1. Switch to key-based logins

On your own computer, create a key and copy it to the server:

ssh-keygen -t ed25519
ssh-copy-id you@your-server

2. Turn off passwords and root login

Edit /etc/ssh/sshd_config (or add a file in /etc/ssh/sshd_config.d/):

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3

Check the file for mistakes, then reload SSH:

sudo sshd -t
sudo systemctl reload ssh      # Ubuntu and Debian
sudo systemctl reload sshd     # RHEL, Fedora, Rocky, AlmaLinux

On Windows Server with OpenSSH, the same settings go in C:\ProgramData\ssh\sshd_config; restart the OpenSSH SSH Server service afterwards.

3. Slow down password guessing with fail2ban

fail2ban blocks addresses that fail to log in repeatedly. On Ubuntu and Debian:

sudo apt install fail2ban

The SSH protection is on by default there. With key-only logins the guesses can't succeed anyway, but fail2ban keeps the logs readable and cuts the load.

4. Limit who can reach port 22

Allow only your office IP address, if it is fixed. With ufw: sudo ufw allow from 203.0.113.10 to any port 22, then remove any rule that allows 22 from anywhere.
In the cloud, change the security group or firewall rule from 0.0.0.0/0 to your own address, or use the provider's browser-based access (AWS Systems Manager Session Manager, Azure Bastion, Google Cloud IAP) and close 22 entirely.
Use a VPN or a mesh network such as Tailscale or WireGuard, and only accept SSH from inside it.

5. Close it where nobody uses it

On a NAS, router or camera, turn SSH off in the device's settings unless someone actually needs it. On a router, also remove any port forwarding rule for 22.

6. Keep OpenSSH updated

Install security updates regularly (sudo apt update && sudo apt upgrade on Ubuntu and Debian), or turn on automatic security updates. Then re-scan to confirm.

What doesn't work on its own

Moving SSH to another port (2222 and so on). It reduces bot noise in the logs, but Nmap's -sV identifies SSH on any port. The service is just as reachable.
A strong password alone. It helps, but it can still be phished, reused elsewhere or leaked. Keys can't be guessed.

If you think someone already got in

Check the login log: /var/log/auth.log on Ubuntu and Debian, or journalctl -u ssh (-u sshd on RHEL). Look for Accepted password or Accepted publickey lines from addresses you don't recognise. Also look for unknown keys in each user's ~/.ssh/authorized_keys and unexpected new user accounts. If you find any, take the machine off the network and get incident response help before cleaning up, so evidence isn't lost.

Common questions

Is port 22 open a vulnerability?

Not by itself. It's an exposed service, which is why FreshScanSentry rates it Low. It becomes a real problem when passwords are accepted, root can log in, or OpenSSH is out of date.

The scan says port 22 is "tcpwrapped".

Something accepted the connection but didn't answer like SSH. It's often a cloud firewall or load balancer. Check your firewall rules and whether anything is actually listening on the server.

Our hosting company manages the server.

Ask them whether SSH allows passwords and root login, and whether it can be limited to your IP address. Many hosts offer this in their control panel.

Sources: OpenSSH sshd_config manual · OpenSSH 9.8 release notes (CVE-2024-6387) · NVD: CVE-2024-6387 · Nmap ssh-auth-methods · fail2ban