Changing the SSH port from 22: what it fixes and what it doesn't

The honest summary

Moving SSH off 22 will cut your failed-login volume by something like 90% overnight. It is also not a security control, and treating it as one is how servers get compromised by administrators who thought they were finished.

Both statements are true because they answer different questions. The volume drop is real, measurable and useful. The protection is close to zero against anyone who spends thirty seconds looking.

Worth doing? Usually yes — as noise reduction, alongside a real defence, never instead of one.

What it genuinely stops

The overwhelming majority of SSH attack traffic comes from untargeted scanners doing one thing: connecting to port 22 across large IP ranges and trying credentials on whatever answers. They do not port-scan, because checking one port across the internet costs orders of magnitude less than checking 65,535, and there are more than enough machines on 22 to keep them busy.

Move to 52200 and you drop out of that population entirely. The graph falls off a cliff, the auth log stops rotating every few hours, and finding a real event in it becomes possible again.

That last point is the underrated benefit. A readable log is worth real money during an incident, and at three thousand failures a day you do not have one.

What it does not stop

Anyone who scans the full port range finds you in minutes. SSH announces itself in the clear — the version banner is the first thing the service sends — so a scanner sweeping all ports and reading banners labels your service correctly on the first try.

Shodan and Censys do exactly this continuously and publish the results as a searchable index. Your non-standard SSH port is in there, findable by anyone, within days.

So against an untargeted bot, moving the port works. Against anyone who chose you, it costs them a few minutes. And it does nothing at all about weak passwords, a leaked key, an unpatched sshd or a vulnerable application on the same host.

There is an active downside too: unusual ports break things. Corporate firewalls that permit outbound 22 will block outbound 52200, and you will learn that from a colleague who cannot deploy.

Changing it without locking yourself out

Two steps get omitted from most guides and both will lock you out on a modern distribution: SELinux port labelling on the RHEL family, and systemd socket activation on recent Debian and Ubuntu, where sshd no longer listens on its own.

Keep your current session open throughout, and work through this in order:

NEWPORT=52200

# 1. Firewall FIRST — before sshd moves anywhere
sudo ufw allow ${NEWPORT}/tcp                                          # Debian/Ubuntu with ufw
sudo firewall-cmd --permanent --add-port=${NEWPORT}/tcp && sudo firewall-cmd --reload   # RHEL family

# 2. SELinux: label the port, or sshd will refuse to bind (RHEL family)
sudo semanage port -a -t ssh_port_t -p tcp ${NEWPORT} || \
  sudo semanage port -m -t ssh_port_t -p tcp ${NEWPORT}

# 3. Tell sshd. Keep 22 listed for now — two ports, so you cannot be cut off
printf 'Port 22\nPort %s\n' "$NEWPORT" | sudo tee /etc/ssh/sshd_config.d/20-port.conf
sudo sshd -t                            # syntax check before anything reloads

# 4. Socket activation: on recent Debian/Ubuntu sshd does not bind by itself
systemctl is-enabled ssh.socket 2>/dev/null && \
  echo 'ssh.socket is enabled — override ListenStream there, see the note below'

sudo systemctl reload ssh               # 'sshd' on the RHEL family

Finish the move

Now verify from a second terminal on the new port — ssh -p 52200 user@server — before touching anything else. Only once that works should you remove Port 22 from the configuration, reload again, and close the old firewall rule.

Then update everything that stored the old port: ~/.ssh/config entries, deployment scripts, CI runners, Ansible inventories, monitoring checks, backup jobs, and your team's documentation. A port change that breaks the nightly backup is worse than no port change.

Do not remove port 22 before confirming the new port works from outside your own network. Inside the LAN everything works either way, which is exactly how people convince themselves it is fine.

What to pair it with

Port changes reduce noise. Something still has to handle the attempts that arrive — and after a port change, the ones that arrive came from someone who looked for you specifically, which are the ones you actually care about.

SSH Protector detects the real SSH port from sshd's effective configuration rather than assuming 22, so a server that has already been moved is covered without configuring anything, and it rebuilds its rules if the port changes again later.

Change the port for a readable log. Keep a defence for the traffic that finds you anyway.