Deutsch
To change SSH port settings safely, open the new firewall rule first, add the new Port value to the OpenSSH server configuration, test the sshd config, reload the service, and only remove the old port after a new SSH session works. The safety order matters more than the port number.
Changing the SSH port can reduce noisy automated login attempts on a VPS, but it is not a replacement for SSH keys, strong users, firewall rules, and disabled password login where appropriate. Treat the port change as one layer in a broader SSH hardening plan.
This tutorial uses port 2222 as an example. Replace it with a port that fits your environment and does not conflict with another service.
Key takeaways
- Keep your current SSH session open until the new port works.
- Open the firewall for the new TCP port before reloading SSH.
- Ubuntu documents
/etc/ssh/sshd_configas the main OpenSSH server configuration file and also supports drop-in snippets. - Test the OpenSSH configuration before reloading the service.
- Verify a second login with
ssh -p 2222 user@server-ipbefore closing port22. - For related security work, see the Virtarix guides to how to secure a VPS, SSH keys on Mac, and Linux command line habits.
Before you change SSH port: avoid lockout
The biggest risk is not picking the wrong number. The biggest risk is locking yourself out of the server. Always keep one working SSH session open while testing the new port in a second terminal.
Before changing anything, confirm:
- you have console or provider panel access if SSH fails;
- your current SSH session stays open;
- your firewall will allow the new port;
- your cloud firewall or provider security group also allows the new port;
- your team knows which port to use after the change.
Do not close port 22 until you have proved that the new port accepts a fresh login.
Safe SSH port change steps
Step 1: choose the new port
Pick a TCP port that is not already used by another service. In this guide, the example port is 2222.
Avoid using another well-known service port. A custom port should make operations clearer, not create future confusion.
Step 2: allow the new port in the firewall first
If you use UFW on Ubuntu, allow the new TCP port before reloading SSH.
ufw allow 2222/tcpIf your VPS provider has a separate cloud firewall, update that too. A local UFW rule cannot help if the provider firewall blocks the port before traffic reaches the server.
Keep the old SSH rule in place during the test. Removing it too early is how admins lock themselves out.
Step 3: add the SSH port directive
Ubuntu documents the main OpenSSH server config at /etc/ssh/sshd_config, with support for drop-in snippets. A small snippet is often cleaner than editing the packaged base file directly.
Use a snippet such as this:
Port 2222If your server already has a Port directive elsewhere, avoid defining conflicting values. The final active configuration should be obvious to the next admin.
Step 4: test the OpenSSH config before reload
Test the config syntax before touching the running service.
sshd -t -f /etc/ssh/sshd_configThe disposable Ubuntu verification container for this guide accepted the example custom-port config after the OpenSSH server package was installed and the runtime directory was present.
If the test fails, do not reload SSH. Fix the configuration and test again.
Step 5: reload SSH and test a second connection
After the firewall and config checks pass, reload OpenSSH through your distribution’s normal service-management workflow. Then open a second terminal and test the new port.
ssh -p 2222 user@server-ipKeep the original SSH session open while testing. If the second connection fails, use the first session to inspect the config, firewall, provider firewall, logs, and service state.
Step 6: remove old-port access only after success
Only after the new SSH login succeeds should you remove or restrict port 22 access. Even then, consider whether an allowlisted admin IP or emergency access path should remain temporarily during the change window.
Document the final port in your server inventory, runbook, password manager note, or team documentation. A port change that is not documented becomes a future incident.
Why changing SSH port is not enough
A custom SSH port can reduce low-effort noise in logs, but it does not make SSH secure on its own. Internet scanners can find services on non-standard ports.
Prioritize controls that actually improve access security:
- key-based authentication;
- disabling password login where practical;
- limiting users who can SSH;
- firewall allowlists for admin networks;
- fail2ban or equivalent monitoring where appropriate;
- prompt patching of OpenSSH and the host OS.
Changing the port is useful when combined with those controls. It is weak when used as the only defense.
Troubleshooting SSH port changes
The new port times out
Check the local firewall, provider firewall, and network path. A timeout often means traffic is not reaching sshd at all.
Connection refused
The firewall may allow the port, but sshd may not be listening there. Re-check the active config and service state.
The config test fails
Do not reload SSH. Fix the syntax first. A failed config test is the warning that prevents a lockout.
The old port still works
That may be expected during the transition. Confirm the new port works first, then decide whether to remove, restrict, or temporarily keep old-port access.
