Change an SSH port safely, including Ubuntu socket activation

Changing the SSH port can reduce routine scanning noise, but it does not replace keys, patching or access control. The technical risk is losing access while the daemon, a systemd socket or a provider firewall still uses a different port. A safer migration runs the old and new ports together until a fresh connection has been verified.

Inventory every place the SSH port is defined

Start by identifying the listener that currently accepts connections. A running ssh.service is not the only possibility: Ubuntu installations can use ssh.socket to own the listening port and activate the daemon on demand. In that case, editing sshd_config and restarting only the service may leave the old socket configuration in place.

sudo ss -lntp
systemctl is-active ssh.socket
systemctl cat ssh.socket
sudo grep -RniE '^[[:space:]]*(Port|ListenAddress)[[:space:]]' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Record existing Port and ListenAddress entries, including provider or cloud-init snippets. Also inspect your VPS Control Panel firewall and any operating-system firewall. A rule in one layer cannot override a block in another layer. Confirm that the proposed port is unused and fits your administration policy.

Permit the new connection path before moving the service

Allow TCP 2222 in each relevant firewall while keeping the working port allowed. With UFW, the following example adds the extra allowance; it does not enable a currently disabled firewall or remove your old access.

sudo ufw status numbered
sudo ufw allow 2222/tcp comment 'SSH migration listener'
sudo ufw status verbose

Use an appropriately restricted source address when your administration network is stable, and account for IPv6 as well as IPv4. If UFW is not your firewall manager, use the manager actually deployed on the host. In Plenty Host's built-in Firewall page, check that the matching rule has been applied before relying on it.

Configure two listening ports during the transition

Use sudoedit to create a dedicated snippet such as /etc/ssh/sshd_config.d/10-plenty-ports.conf. The temporary configuration below retains port 22. Port accepts multiple entries, unlike many single-value sshd settings, so inspect all existing snippets rather than assuming this file is the entire configuration.

Port 22
Port 2222

sudo sshd -t
sudo sshd -T | grep -E '^(port|listenaddress) '

An empty result from sshd -t means the syntax test succeeded. It does not prove a firewall path or a live listener. Keep authentication policy unchanged during this port migration so that you are testing one change at a time.

Apply the correct service or socket workflow

For Ubuntu's socket-activated OpenSSH package, a systemd generator derives listening sockets from the SSH configuration. Reload systemd's generated configuration and restart the socket, then inspect the real listeners. Use the console during this step if you are uncertain how your installation ties the service to its sockets.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -lntp | grep -E ':(22|2222)[[:space:]]'

On an installation that is managed directly by ssh.service instead of ssh.socket, validate first and use sudo systemctl restart ssh.service. Do not blindly run both branches. If the expected listener is missing, inspect systemctl status and the SSH journal from the retained session or console before changing any more rules.

Verify from a separate workstation session

ssh -p 2222 -o ControlMaster=no -o ControlPath=none \
  vpsuser@server.example.com

Verify the server host key and confirm the account can perform the administration you need. Test from each authorized access path you depend on, including IPv6 if used. A local listener check cannot detect an upstream firewall block, while a TCP connection alone does not prove that authentication succeeds.

Only after this test should you update workstation SSH configuration, deployment tools, monitoring checks and documented recovery instructions. Search automation for old -p 22 or Port 22 settings. A migration is incomplete if a scheduled backup transfer still attempts the old port.

Retire the old port and keep a rollback route

Remove the temporary old-port allowance only when the new path and recovery console have been proven. If you also remove the old listener, edit every relevant Port or ListenAddress entry, validate again and apply the same service/socket workflow. Recheck ss and a new external login afterward.

If access fails, restore the previous configuration through the console and restore the necessary firewall allowance. Do not disable all security controls to diagnose a single missing port. Record the final listening port, allowed sources and configuration file so the next maintenance change starts from an accurate baseline.

Primary documentation

• OpenSSH server configuration
• Ubuntu OpenSSH socket activation and port changes
• Ubuntu host firewall configuration