How to Change the Default SSH Port (and Should You?)

Does Changing the Port Help?

Changing SSH from port 22 to a non-standard port — such as 2222, 2244, or any unused port above 1024 — is a technique known as “security through obscurity.” It is not a security control in its own right, but it is a genuinely useful noise reducer. Automated scanners and botnets that probe the internet for SSH servers almost universally target port 22. Move to a custom port and those bots will pass right over your server, cutting the volume of failed login attempts in your auth logs by more than 90%.

However, obscurity is not security. A targeted attacker will run a full port scan across all 65,535 ports and find your SSH daemon wherever it is listening. That is why the correct strategy is to use both: change the port to eliminate automated scan noise, and use SSH key authentication to make brute-force attacks computationally infeasible. Together, these two measures eliminate nearly all automated intrusion attempts.

How to Change the SSH Port

The SSH daemon reads its configuration from /etc/ssh/sshd_config. To change the listening port, open that file and set the Port directive. Choose any unused port above 1024 and below 65535 — port 2244 is a common choice. Always test the configuration before reloading so a syntax error does not break your connection.

The sudo sshd -t command performs a dry-run config test and will report any errors before anything changes. Only run the reload after you see no output from the test — no output means no errors.

Update Firewall Rules

Changing the port in sshd_config is only half the job. If your firewall is blocking the new port, the connection will fail and you will be locked out. The critical rule: open the new port in UFW and keep port 22 open until you have confirmed the new port is working from a separate terminal session. Only then is it safe to close port 22.

Connecting on a Custom Port

Once your server is running SSH on a non-standard port, every client tool needs to be told about it. The ssh command uses the lowercase -p flag. Note that scp uses uppercase -P, and rsync passes the port through its -e option:

Adding a Port directive to your ~/.ssh/config is the cleanest solution — you only specify the port once, and every tool that respects the config file (ssh, scp, rsync, git over SSH) picks it up automatically. This approach is covered in depth in the SSH config files guide.

Risks and Tradeoffs

Moving SSH off port 22 is not without friction. Many tools, scripts, and services assume the default port and will need to be updated. Here is what to audit after making the change:

• Fail2ban SSH jail: Fail2ban watches port 22 by default. After changing ports, update /etc/fail2ban/jail.local with port = 2244 under the [sshd] jail definition, then restart Fail2ban.
• Existing ~/.ssh/config aliases: Any Host blocks pointing to this server need a Port 2244 line added, both on your local machine and for any team members who have saved configs.
• GitHub / GitLab deploy keys: Git SSH remotes default to port 22. If you have set the server as a Git remote directly (not via a service like GitHub), update the remote URL to include the port.
• Deployment scripts and CI pipelines: Any automated scripts using ssh, scp, or rsync to this server must have the port flag added.
• Monitoring tools: Uptime monitors and server monitoring agents that check SSH availability need to be pointed at the new port.

Port scanning can still find an open non-standard port. The benefit is primarily eliminating automated noise — a targeted attacker will enumerate all ports regardless. Changing the port is worth doing if you want cleaner auth logs and fewer false-positive Fail2ban bans from scan traffic; it is not a substitute for key-based authentication, strong firewall rules, or other real security controls.

CloudStick SSH Settings

CloudStick's SSH Settings Management section — available on the Basic plan and above — surfaces your current SSH configuration from within the dashboard. You can review key directives without needing direct command-line access. Custom port changes made manually via sshd_config still take effect on the server regardless; CloudStick simply reads whatever is currently active.

If you use a non-standard SSH port and also use CloudStick's browser-based SSH terminal to access your server, update your SSH config for that connection as well. The SSH Vault in CloudStick stores key references centrally, and the SSH Key Management section lets you add or revoke authorized keys for any system user without touching the command line — a clean complement to the manual port change steps above.