Back to tutorials
Tutorial

SSH Port Change Tutorial (2026): Move Linux VPS SSH to a New Port Safely (No Lockouts, Firewall, SELinux, and Fail2Ban)

SSH port change tutorial for a Linux VPS in 2026: migrate safely, update firewall/SELinux, and prevent lockouts with tests.

By Anurag Singh
Updated on Sep 28, 2026
Category: Tutorial
Share article
SSH Port Change Tutorial (2026): Move Linux VPS SSH to a New Port Safely (No Lockouts, Firewall, SELinux, and Fail2Ban)

Changing your SSH port won’t “secure” a server by itself. It will, however, cut drive-by scans and reduce log noise.

This SSH port change tutorial walks you through moving a Linux VPS or dedicated server to a new SSH port without lockouts. It also keeps your firewall rules, SELinux, and Fail2Ban aligned.

The safe sequence is always the same. Keep your current SSH session open. Add a second listening port, confirm a new login works, then close the old door.

Follow that order to avoid the usual mistakes.

What you’ll build (and what you need)

You’ll configure OpenSSH to listen on a new port (example: 2222). You’ll update your firewall, verify access from a second terminal, and then retire port 22.

These steps apply to Ubuntu 24.04/26.04, Debian 12/13, AlmaLinux/Rocky 9/10, and CentOS Stream 9/10.

  • Prereqs: Root or sudo access, plus at least one existing SSH session you keep open.
  • Strongly recommended: SSH keys already working (you can disable password logins after the port move is confirmed).
  • Port choice: Pick a port in 1024–65535 that no other service uses. If you want fewer scans, avoid common alternates like 2222.

If you manage customer systems, schedule a quiet maintenance window.

Warn anyone with shell access before you start.

If you want guardrails—especially around hardening changes—managed VPS hosting from HostMyCode is aimed at this kind of operations work.

Step 1: Snapshot or console access before you touch SSH

Before you edit anything, make sure you can recover if SSH doesn’t come back.

On a VPS, take a snapshot if your provider supports it.

At minimum, confirm you can reach an out-of-band console or VNC from the control panel.

  • VPS snapshot: Take one immediately before changes.
  • Console check: Verify you can open a recovery console if SSH breaks.

If you want a repeatable rollback flow, keep this handy: VPS snapshot tutorial.

Step 2: Confirm your current SSH baseline

From your existing SSH session, check what sshd thinks its live configuration is.

Leave this session open until the very end.

Also confirm which ports sshd is currently listening on.

sudo sshd -T | egrep '^(port|listenaddress|passwordauthentication|pubkeyauthentication)'

sudo ss -lntp | grep sshd

Why this matters: many current distributions use include files and drop-ins for sshd.

If you edit the wrong file, nothing changes. You may not notice until you start testing.

Step 3: Add the new SSH port (don’t remove 22 yet)

Edit the SSH daemon configuration. The main file is usually /etc/ssh/sshd_config.

On newer builds, you may also have drop-ins in /etc/ssh/sshd_config.d/*.conf.

Option A (simple): edit the main file.

sudo nano /etc/ssh/sshd_config

Add a second Port line (or adjust your existing ones). Example:

# Keep 22 temporarily until you validate new access
Port 22
Port 2222

Option B (cleaner on modern systems): use a drop-in file.

sudo install -d -m 755 /etc/ssh/sshd_config.d
sudo nano /etc/ssh/sshd_config.d/10-custom-port.conf
Port 2222

Keep port 22 enabled for now.

Remove it only after you confirm a successful login on the new port.

Step 4: Validate config before restarting sshd

Don’t restart sshd on faith. Run a syntax check first.

One bad line can prevent SSH from starting.

sudo sshd -t

No output means the config parses cleanly. If you get an error, fix it before you reload anything.

Step 5: Open the new port in your firewall (UFW and firewalld)

This is where lockouts usually happen. sshd may be listening on the new port, but the firewall can still drop the traffic.

Allow the new port before you reload SSH.

Ubuntu/Debian (UFW)

sudo ufw allow 2222/tcp
sudo ufw status verbose

If you run a strict allowlist, scope the rule to your office IP:

sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp

AlmaLinux/Rocky/CentOS Stream (firewalld)

sudo firewall-cmd --add-port=2222/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

If your provider also has a “cloud firewall” or security group, open the same port there as well.

Leave port 22 open until you’ve confirmed real logins over the new port.

If you want a step-by-step firewall sanity check, this guide fits well here: VPS firewall setup guide.

Step 6: SELinux (RHEL-family) — allow sshd to bind the new port

If SELinux is enforcing, sshd can’t bind to arbitrary ports until you label them.

On AlmaLinux/Rocky/CentOS Stream, start by checking mode:

sestatus

If it shows Enforcing, add (or modify) the SSH port type:

sudo semanage port -a -t ssh_port_t -p tcp 2222 || sudo semanage port -m -t ssh_port_t -p tcp 2222
sudo semanage port -l | grep ssh

Note: semanage is provided by policycoreutils-python-utils on many systems.

sudo dnf -y install policycoreutils-python-utils

Step 7: Reload SSH and confirm it’s listening on both ports

Reload the SSH service. Reload is preferred.

A restart is fine if reload isn’t available on your unit name.

sudo systemctl reload ssh || sudo systemctl reload sshd
sudo systemctl status ssh --no-pager || sudo systemctl status sshd --no-pager

Then confirm sshd is actually listening on both ports:

sudo ss -lntp | grep sshd

You should see listeners on :22 and :2222.

Step 8: Test a NEW login on the new port (don’t close your current session)

From your workstation, open a second terminal.

Connect explicitly on the new port.

ssh -p 2222 youruser@your.server.ip

If you use an SSH client config, make it persistent there:

nano ~/.ssh/config
Host hostmycode-vps
  HostName your.server.ip
  User youruser
  Port 2222
  IdentityFile ~/.ssh/id_ed25519

Test the shortcut:

ssh hostmycode-vps

If that new session works, you’re ready to remove port 22.

If it fails, stop and troubleshoot while 22 is still available.

Step 9: Update Fail2Ban (so bans match the port you actually use)

Fail2Ban often ships with an sshd jail that assumes port 22.

Because Fail2Ban is log-driven, it may still detect attacks. However, the firewall action can target the wrong port if you don’t update it.

Check your current status first:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Then set an override (recommended approach):

sudo nano /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
port = 2222
maxretry = 5
findtime = 10m
bantime = 1h

Restart Fail2Ban to apply changes:

sudo systemctl restart fail2ban

If you haven’t done baseline hardening (keys, sudo rules, and cutting down obvious noise), follow the order of operations in Server Hardening Tutorial (2026). It complements a port move nicely.

Step 10: Close port 22 (only after successful new-port logins)

After you successfully log in via the new port using a fresh session, remove port 22 in two places.

Update the sshd config and the firewall.

Remove port 22 from sshd

Edit the same file you used earlier. Leave only the new port:

sudo nano /etc/ssh/sshd_config
Port 2222

Validate and reload again:

sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

Remove firewall access to 22

UFW:

sudo ufw delete allow 22/tcp
sudo ufw status

firewalld:

sudo firewall-cmd --remove-service=ssh --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Important: removing the ssh service in firewalld closes port 22.

Make sure 2222/tcp is explicitly allowed first.

Step 11: Tighten SSH authentication (keys only, fewer surprises)

A port change cuts noise. Key-only auth cuts real risk.

If keys already work end-to-end, these settings are a sensible next step:

sudo nano /etc/ssh/sshd_config.d/20-auth-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthenticationMethods publickey

Then validate and reload:

sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

If multiple admins access the box, plan a quick key hygiene pass.

This walkthrough helps you rotate access without surprises: SSH key rotation tutorial (2026).

Quick diagnostics: if the new port doesn’t work

Work the stack from inside out. Run one check per layer, in order.

  1. Is sshd listening? 
    sudo ss -lntp | grep sshd
  2. Is the firewall open locally? 
    sudo ufw status verbose
sudo firewall-cmd --list-all
  3. Is your provider firewall/security group open? Confirm the inbound rule exists for TCP 2222.
  4. SELinux blocking? 
    sudo ausearch -m AVC -ts recent | tail -n 30
sudo semanage port -l | grep ssh
  5. Client-side issue? Try a raw TCP test from your workstation: 
    nc -vz your.server.ip 2222

If you’re coordinating changes on a production VPS, a tighter overall change plan helps.

The testing and rollback habits in DNS Cutover Tutorial (2026) apply just as well to “small” access changes.

Operational checklist for teams and resellers

  • Record the new SSH port in your runbook/password manager.
  • Update monitoring that assumes port 22 (uptime probes, security scanners).
  • Update automation that hard-codes port 22 (Ansible inventory, deploy scripts, Git hooks).
  • Keep a break-glass option: provider console, rescue ISO, or snapshot rollback.
  • Pair the port move with key-only auth and rate limiting (Fail2Ban) for real risk reduction.

Summary: a safer SSH port migration in 10 minutes

The safe pattern is consistent: allow the new port, configure sshd to listen on both ports, validate a fresh login, then remove port 22 and tighten auth.

Stick to that order and you avoid the common lockout traps.

If you’re standardizing access controls across several servers, use a template.

Review changes consistently.

HostMyCode offers HostMyCode VPS plans for hands-on admins, and managed VPS hosting when you want the operational overhead handled.

If you’re moving sites onto a VPS, set your baseline before you pile on services: clean SSH access, sane firewall rules, and a rollback plan you’ve actually tested. HostMyCode keeps that simple with HostMyCode VPS for full control, or managed VPS hosting if you want security changes applied and reviewed for you.

FAQ

Does changing the SSH port really improve security?

It reduces opportunistic scans and brute-force noise. That cleans up logs and cuts random password-guessing attempts.

Real security comes from SSH keys, disabling passwords, and tight firewall rules.

What’s a good SSH port to use in 2026?

Use an unused port above 1024. If you want fewer automated hits, avoid common alternates like 2222.

The number matters less than documenting it and using it consistently.

Will this break SFTP or Git deployments?

SFTP rides over SSH, so it follows the port change.

Update clients and automation that assumes port 22 (CI jobs, deploy scripts, IDE connections, and backup pulls).

How do I avoid locking myself out?

Keep your current SSH session open. Add the new port without removing 22.

Open the firewall, reload sshd, and validate a brand-new login on the new port. Only then remove port 22.

Do I need to update Fail2Ban?

If your Fail2Ban action targets a specific port, yes.

Set port = 2222 in the [sshd] jail and restart Fail2Ban so bans apply correctly.