Harden Your VPS SSH: Change the Port and Disable Root Login

Securing remote access to a virtual private server (VPS) is one of the first priorities for any site owner, developer, or IT team. SSH is the default administrative gateway for Linux-based instances, and while it is a robust protocol, leaving it on default settings (port 22, root login enabled) exposes the server to automated scans, brute-force attempts, and targeted attacks. In this article we will explain the technical principles behind changing the SSH port and disabling root login, show concrete steps and firewall considerations, compare the advantages and trade-offs of these measures, and offer practical guidance on when and how to apply them on production VPS instances.

Why modify SSH defaults?

Out of the box, most distributions run SSHD on TCP port 22 and accept authentication for root by default (or at least allow root logins). Two common attack vectors target these defaults:

• Automated scanning and brute-force: Attackers scan the internet for accessible port 22 and then attempt brute-force username/password combinations, or try common keys.
• Privilege escalation via direct root login: If root login is permitted and credentials are compromised, an attacker gains immediate full control.

Changing the SSH port to a non-standard value (for example, 2222 or another high-numbered port) does not make SSH invulnerable, but it reduces noise from opportunistic scanners and lowers the number of automatic brute-force attempts. This is a security-through-obscurity layer that, combined with other controls (SSH keys, fail2ban, firewall policies), improves overall resilience.

Disabling root login forces administrative access through a non-privileged account, which then escalates privileges via sudo. This adds an auditable step, prevents attackers from being instantly root if credentials are leaked, and allows for better accountability and safer brute-force mitigation (e.g., lock the user rather than expose root).

How it works: configuration and system interactions

SSH daemon configuration is located at /etc/ssh/sshd_config on most Linux distributions. Two directives control port and root access:

• Port — defines the TCP port number SSH listens on (default 22). One can specify multiple Port directives.
• PermitRootLogin — controls root login behavior. Useful settings include no, prohibit-password, and without-password (terminology varies slightly by OpenSSH version).

At the system level, the SSH daemon is bound to the chosen port. The firewall (iptables, nftables, ufw, firewalld) must be configured to permit the new port; otherwise the server will be inaccessible. If the VPS uses SELinux, port changes may require adding the port to the ssh_port_t context using semanage or adjusting SELinux policies. Additionally, host-based access control (AllowUsers, AllowGroups) and PAM settings interact with authentication and session creation.

Example minimal configuration changes

Typical modifications in /etc/ssh/sshd_config are:

Change or add port: Port 2222

Disable root login: PermitRootLogin no

Optionally enforce key-based auth and disable passwords: PubkeyAuthentication yes and PasswordAuthentication no

Always retain a secondary session while testing to avoid lockout.

Step-by-step: change port and disable root without locking yourself out

Follow these steps to minimize service interruption and risk of locking yourself out of the VPS.

• 1) Ensure you have a non-root administrative user with sudo privileges and working SSH key authentication. Create one if needed: for example, as root run adduser deploy; usermod -aG sudo deploy, then add your public key to /home/deploy/.ssh/authorized_keys with correct permissions.
• 2) Keep an existing root shell open (or open a serial/console session available through your VPS provider) while testing — this provides an emergency fallback to revert changes.
• 3) Edit /etc/ssh/sshd_config. Modify Port and PermitRootLogin values. Example changes: Port 2222 and PermitRootLogin no. Also consider setting PasswordAuthentication no if you have key auth ready.
• 4) Update firewall rules to allow the new port. Examples: for UFW run ufw allow 2222/tcp then ufw reload. For firewalld: firewall-cmd –permanent –add-port=2222/tcp; firewall-cmd –reload. For iptables: add an INPUT rule permitting tcp dpt:2222 and save the configuration.
• 5) If using SELinux, add the new port: semanage port -a -t ssh_port_t -p tcp 2222. If semanage is not installed, install policycoreutils-python-utils (or the distro equivalent).
• 6) Test the new connection from a separate terminal: ssh -p 2222 deploy@your_server_ip. Do not close the original session until the new session is confirmed successful.
• 7) If the test succeeds, restart SSH: systemctl restart sshd (or service sshd restart depending on your distro). Then close the old root session.
• 8) If anything goes wrong and you are locked out, use your VPS control panel’s console/serial access to revert changes to /etc/ssh/sshd_config or firewall rules.

Firewall and logging considerations

When moving SSH off port 22, update your firewall rules but avoid removing port 22 until you’ve verified the new port works. In cloud or provider-managed networks, you must also adjust security groups or VPC firewall rules. Log analysis remains important: ensure your SSH logs (usually /var/log/auth.log or journalctl -u sshd) are monitored and rotated. Forward logs to a centralized logging system for correlation and quicker incident response.

Combine port changes with rate limiting and intrusion prevention:

• Install and configure fail2ban to parse logs and temporarily block IPs with repeated failed logins. For example, create a jail for sshd and set bantime and maxretry appropriate for your environment.
• Use iptables/nftables rate-limiting rules (e.g., limit packets per minute) to reduce brute-force effectiveness.
• Consider geo-blocking if your administrative traffic originates from known regions only.

Advantages and trade-offs

Advantages:

• Reduced automated noise: non-standard ports see far fewer scans, cutting down on log clutter and automated attacks.
• Increased attack complexity: attackers must first discover the port and then exploit it, giving defenders additional time and indicators.
• Better accountability: disabling root ensures administrative actions are performed under named accounts with sudo, improving auditing.
• Layered security: port changes complement stronger controls (keys, MFA, IP whitelisting) to form defense-in-depth.

Trade-offs and caveats:

• Obscurity is not a substitute: a port change delays but does not prevent a determined attacker who scans all ports.
• Operational overhead: you must update documentation, automation scripts, monitoring alerts, and any orchestration tooling (Ansible, Terraform, etc.) that connects via SSH.
• Compatibility: some managed systems or corporate proxies assume port 22; moving can complicate remote worker access if outbound filters block non-standard ports. In such cases, consider port 443 or adding a bastion host in a DMZ accessible on standard ports.

Application scenarios and best practices

Tailor your SSH hardening approach to the use case.

Single administrator or small team

• Use key-based authentication only, disable PasswordAuthentication, and disable root. Change the port to reduce random scans.
• Enable fail2ban with conservative thresholds and keep a backup console session for recovery.

Large teams or CI/CD integration

• Implement an SSH bastion host with centralized logging and multi-factor authentication. Enforce jump-host usage via AllowUsers and Auditd.
• Use centralized key management (SSH certificates using a CA) rather than populating ~/.ssh/authorized_keys on every host.

High compliance or regulated environments

• Disable root. Require unique accounts and use sudo auditing. Prefer SSH certificates and implement MFA where possible.
• Document firewall rules and port changes in change control systems and maintain configuration as code for auditability.

Recommendations for choosing and operating a VPS

When selecting a VPS provider or plan, consider network and management features that affect SSH hardening:

• Does the provider offer out-of-band console/serial access? This is critical when you accidentally lock yourself out of SSH.
• Are firewall/security group controls available at the network level, so you can apply rules even before instance-level firewalls take effect?
• Does the provider support private networking or a VPN for administrative access, enabling you to restrict SSH to internal IP ranges?
• Evaluate performance and SLA of the VPS for your workload; administrative security is one piece—reliable uptime and support are complementary.

For those deploying from the United States or expecting US-based traffic, consider VPS options optimized for regional latency and compliance. Learn more about VPS offerings at VPS.DO and their US-hosted instances at USA VPS.

Summary

Changing the SSH port and disabling root login are straightforward, high-impact measures that reduce your VPS’s exposure to automated attacks and limit the blast radius if credentials are compromised. However, these actions are most effective when combined with stronger authentication (SSH keys, certificates), rate limiting and automated blocking (fail2ban or firewall rules), and provider-level protections such as security groups and console access. Always test changes from a separate session and keep an out-of-band recovery path. For reliable VPS platforms with management features that support secure administration, explore VPS.DO and their USA VPS options for geographically optimized deployments.