Moving SSH off port 22 doesn’t make a server secure by itself — that’s what SSH keys are for — but it does eliminate most of the automated scanning noise in your logs. The change is quick; the risk is locking yourself out. Follow the steps in order.

Before you start

  • Pick a port between 1024 and 65535 that nothing else uses, e.g. 2222 or something less common like 49222. Check: sudo ss -tlnp | grep ':49222' should print nothing.
  • Keep your current SSH session open throughout. Test the new port in a second terminal.
  • Know how to reach your VPS console (VNC in your provider’s panel) in case something goes wrong.

1. Allow the new port in the firewall first

UFW (Ubuntu/Debian):

sudo ufw allow 49222/tcp

firewalld (AlmaLinux/Rocky):

sudo firewall-cmd --permanent --add-port=49222/tcp
sudo firewall-cmd --reload

If your provider has a network firewall or security group, open the port there too.

2. Change the port in the SSH config

Create a drop-in file — cleaner than editing the main config and safe from package updates:

echo "Port 49222" | sudo tee /etc/ssh/sshd_config.d/10-port.conf

Make sure /etc/ssh/sshd_config contains Include /etc/ssh/sshd_config.d/*.conf near the top (it does on current Ubuntu, Debian and RHEL-family releases) and that no other Port line conflicts. Check for syntax errors:

sudo sshd -t

No output means the config is valid.

3a. Ubuntu 22.10 and later: socket activation

Recent Ubuntu releases start SSH through systemd socket activation (ssh.socket), and the listening port is taken from the socket, not directly from sshd. On Ubuntu 24.04, a systemd generator reads the Port setting from your sshd config and updates the socket — but only after a reload:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

If your system doesn’t pick up the change, override the socket explicitly:

sudo systemctl edit ssh.socket
[Socket]
ListenStream=
ListenStream=49222

The empty ListenStream= clears the default port 22. Then sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Alternatively, switch back to the classic service: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service.

3b. Debian, older Ubuntu: restart the service

sudo systemctl restart ssh

3c. AlmaLinux / Rocky: tell SELinux about the port

SELinux only allows sshd to bind to labelled ports. Without this step, sshd fails to start:

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 49222
sudo systemctl restart sshd

4. Verify it’s listening

sudo ss -tlnp | grep ssh

You should see :49222. If you still see only :22, revisit step 3.

5. Test from a second terminal

ssh -p 49222 [email protected]

Only when this works should you close the original session.

6. Close port 22

sudo ufw delete allow OpenSSH       # or: sudo ufw delete allow 22/tcp
sudo firewall-cmd --permanent --remove-service=ssh && sudo firewall-cmd --reload

7. Update your clients

Save the port in ~/.ssh/config so you don’t have to remember it:

Host myvps
    HostName 203.0.113.10
    User deploy
    Port 49222

Now ssh myvps, scp file myvps: and rsync … myvps: all use the right port. Also update:

  • Fail2Ban: port = 49222 in the [sshd] jail.
  • Deployment tools, CI secrets and backup scripts that connect over SSH.
  • Git remotes using SSH: ssh://git@host:49222/repo.git.

If you get locked out

Log in through your VPS’s VNC console in the client area — it doesn’t depend on SSH or the firewall. Then:

sudo ufw allow 49222/tcp          # or re-allow 22
sudo sshd -t                      # look for config errors
sudo systemctl status ssh ssh.socket
sudo journalctl -u ssh -n 30

Common causes: the firewall rule was missing, SELinux blocked the port, or socket activation still listens on 22.

Is changing the port worth it?

Pros: far fewer bot login attempts and smaller logs; Fail2Ban has less to do. Cons: a minor inconvenience for every client and tool; some restrictive networks block non-standard outbound ports.

What actually protects SSH:

  1. Key-based authentication with passwords disabled.
  2. No direct root login.
  3. A firewall, ideally limiting SSH to known IPs or a VPN.
  4. Up-to-date OpenSSH.

A non-standard port is a nice extra on top. For the full list, see the SSH hardening guide.

  • SSH
  • Security
  • Linux