How to Change the SSH Port Safely

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_config as 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-ip before closing port 22.
• 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/tcp

If 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 2222

If 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_config

The 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-ip

Keep 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.

Post-change verification checklist

After the new SSH port works, record the change in the same place your team stores server access notes. Include the port, the firewall rule, the provider firewall rule if one exists, the date of the change, and the rollback plan. This is operational documentation, not paperwork. If another admin needs emergency access later, they should not have to guess which SSH port is active.

Also watch login logs and monitoring after the change. Fewer random attempts can make logs easier to read, but a quiet log does not prove the server is secure. Continue reviewing authentication failures, package updates, firewall exposure, and user access.

FAQ

What is the default SSH port?

The conventional SSH port is 22. This guide uses 2222 as an example custom port, but any chosen port should be checked for conflicts and documented.

Does changing the SSH port improve security?

It can reduce noise from automated login attempts, but it is not a complete security control. Use SSH keys, firewall rules, user restrictions, and sane authentication settings as the main protections.

Should I close port 22 immediately?

No. Keep port 22 available until you have confirmed a fresh SSH login on the new port. Then remove or restrict old-port access according to your access plan.

Summary

The safest way to change SSH port settings is to protect access first: keep the current session open, open the firewall for the new port, add the Port directive, test sshd, reload safely, and verify a second login before touching port 22.

On a VPS, the goal is not only fewer SSH log messages. The goal is a documented, recoverable access path that improves security without creating a lockout risk. Virtarix Cloud VPS plans give you a clean server environment for practising SSH hardening and firewall changes before applying them to production.

Byline: Peter French — Updated 2026-05-18.