Changing the SSH port is the first thing most of us did to a fresh server, usually right after the second coffee. It feels like progress: the log stops scrolling quite so fast. But it is worth being clear about what that one line in sshd_config buys you, because it is less than it looks.
What changing the port actually does
Most internet-wide attack traffic is cheap and automated. Bots sweep the default port, try a list of usernames and passwords, and move on. Move SSH from 22 to 2222 and most of that traffic never reaches your daemon. Your authentication log gets quieter, and real events become easier to spot.
That is a genuine benefit. It is an operational one.
What it doesn’t do
The service is still there. Port scanners don’t guess which port SSH is on — they check all of them and identify the service from its response. A server answering on 2222 replies with an SSH banner, version and all, exactly as it would on 22.
Scanning is also fast. The open-source scanner masscan is documented as able to scan the entire internet for a given port in under five minutes from a single machine. Sweeping every port on one server you have already found takes far less. A non-standard port moves you down the list; it does not take you off it.
So the risks of an exposed SSH service stay where they were:
- Password guessing, now from attackers who bothered to look.
- Daemon vulnerabilities. A flaw in the SSH server is exploitable on any port it listens on.
- Version fingerprinting, which tells an attacker which flaws to try.
How the usual fixes compare
| What you do | Bot noise | Hides the service | Stops a targeted attack |
|---|---|---|---|
| Move SSH off port 22 | Much less | No | No |
| Keys only, fail2ban, rate limits | Less | No | Partly — guessing gets harder |
| VPN or bastion host in front | Less | Moves it to the gateway | Partly — the gateway is now exposed |
| No inbound listener at all | None | Yes | Removes the attack path |
Each step in that table helps. Only the last one changes what an attacker can see.
What to do instead
Keep the port change if you like the quieter logs. Then do the things that actually raise the bar:
- Turn off passwords. Set
PasswordAuthentication noand use keys — ideally hardware-backed FIDO2 keys. CISA calls FIDO the only widely available phishing-resistant form of authentication. - Disable direct root login with
PermitRootLogin no. - Patch the SSH daemon promptly. If it is reachable from the internet, its patch window is your exposure window.
- Restrict who can reach it with source-IP allow-lists where that is practical.
- Remove the inbound exposure. CISA’s current guidance is blunt: close or restrict any port without a documented operational need. For the remote access you do need, its advice for industrial systems — route it through a secure gateway or centrally managed access solution, never straight to the device — applies just as well to servers.
That last point is the zero-trust idea in NIST SP 800-207 applied to one port: access is granted per identity, per session, rather than to anyone who can reach an address.
Where SSHepherd fits
This is the gap SSHepherd® is built for. It closes the listening SSH port on the server entirely; the server and your administrators both connect outward to a broker, which joins them only for authorised identities. Your SSH client and keys work as before, but a scan of the server finds nothing to answer — on port 22 or any other. Sessions can be watched, recorded and ended on demand.
The bottom line
Change the port for tidier logs, not for safety. If SSH is reachable from the internet, the protection comes from strong authentication, fast patching and, above all, not leaving a listener open for anyone to find.