Change Your Ubuntu SSH Port: Open the New Door Before Closing the Old One

You changed the SSH port. Ubuntu kept answering on the old one. No, your VPS is not ignoring you on purpose: on some newer installations, ssh.socket is holding the door keys.

This short guide changes 22 to 52783, uses a fictional example port (52783; choose an unused port for your own server), keeps the old entrance open while you test, and uses single-line commands that are easier to paste into VNC. No terminal origami required.

Use this recipe only for: a normally configured Ubuntu VPS with working SSH on port 22, active ssh.socket, IPv6 enabled in the OS, and no custom restrictions on listening addresses. For a broken SSH setup, an IPv4-only kernel or custom configuration, use our full troubleshooting guide. This is a simple planned change, not a universal repair script.

1. Open your spare entrance

Open the hosting panel’s VNC or serial console and sign in. Keep it open until the new SSH connection works. Run the server commands there, one box at a time. First become root:

sudo -i

Already root? Skip that command. Check the socket:

systemctl is-active ssh.socket

Continue only if it says active. Check that 52783 is unused:

ss -ltnp 'sport = :52783'

A header with no listening rows is expected. If a process appears, choose another unused port rather than evicting it.

2. Let the new visitor through the firewall

Allow TCP 52783 in your provider firewall or security group, preferably from your management IP. Keep port 22 allowed for now.

ufw status

If UFW says active, run:

ufw allow 52783/tcp

If it is inactive or not installed, skip that command; do not enable a new firewall mid-move. If another firewall manages this VPS, allow the port there too.

3. Give the socket two door numbers

First save the existing local systemd configuration:

cp -a /etc/systemd/system /root/systemd-before-ssh-port-$(date +%Y%m%d-%H%M%S)

mkdir -p /etc/systemd/system/ssh.socket.d

Paste this as one line, then press Enter:

printf '%s\n' '[Socket]' 'ListenStream=' 'BindIPv6Only=both' 'ListenStream=22' 'ListenStream=52783' > /etc/systemd/system/ssh.socket.d/zz-tudcloud-port.conf

This local override temporarily opens both ports. Each port uses one dual-stack listener, avoiding separate IPv4 and IPv6 wildcard listeners fighting over the same address. We are changing the socket configuration, so leave the packaged unit and generated files alone. This method remains dependent on socket activation; revisit it if you later switch to service-only SSH.

4. Apply it from the console

Validate first:

/usr/sbin/sshd -t

No output means the check passed. If it reports an error, stop and fix that first. Then run each box separately; stop on any error:

systemctl daemon-reload

systemctl show ssh.socket -p Listen

Check that the intended listeners are 22 and 52783. Unexpected addresses mean another override needs review; use the full guide rather than continuing blindly.

systemctl stop ssh.socket ssh.service

systemctl start ssh.socket

systemctl start ssh.service

ss -ltnp 'sport = :22 or sport = :52783'

You should see both ports listening. Starting and stopping SSH can interrupt access, which is why the console is your spare entrance.

5. Test the new door from your computer

Open a new terminal on your own computer, not inside VNC. Replace the username and IP:

ssh -p 52783 your_user@YOUR_SERVER_IP

Log in fully and check that your normal administrative access works. If you manage over IPv6 too, test that address separately. Timeout? Recheck the firewalls. Connection refused? Recheck the listener. Do not close port 22 yet if this test fails.

6. Close the old door after the new one works

Back in the console, replace the temporary two-port override with the final one:

printf '%s\n' '[Socket]' 'ListenStream=' 'BindIPv6Only=both' 'ListenStream=52783' > /etc/systemd/system/ssh.socket.d/zz-tudcloud-port.conf

Repeat Step 4 and test Step 5 again. This time only 52783 should listen. Remove the old port-22 allowance from your provider firewall and active OS firewall after confirming success. Review the actual rules: an OpenSSH firewall profile can also allow 22.

Update saved SSH connections and deployment tools. During a maintenance window, keep the console available, reboot and test again. Congratulations: you moved the door without leaving yourself on the pavement.

If something goes wrong

Stay in the console. If this guide created zz-tudcloud-port.conf for the first time, remove only that file, then repeat the reload/stop/start commands in Step 4 to return to the prior socket configuration. If the file already existed, restore its previous copy from the backup instead. Keep or restore the old firewall rule. For diagnosis:

journalctl -u ssh.socket -u ssh.service -n 30 --no-pager

A different port is not a stronger lock. Keep SSH keys, updates and appropriate access restrictions. Need a VPS for your project? Browse TudCloud Hong Kong VPS or Seattle VPS and confirm recovery-console availability for your plan.

Technical references: Ubuntu socket activation and systemd socket settings. Reviewed October 15, 2026; this guide is documentation-based, not a test of every Ubuntu image.