Lockout prevention: These steps assume a Linux server you administer. Before changing SSH or firewall rules, confirm working provider-console or rescue access, keep the existing SSH session open and test a second independent session. Record the actual SSH port. Do not copy commands blindly into a managed or production server.

A freshly provisioned VPS or dedicated server is a blank slate — which also means it’s wide open. Here’s a practical checklist for the first 30 minutes.

1. Create a Non-Root User

Set up a separate user with sudo privileges for daily use, and reserve direct root login for emergencies only.

2. Set Up SSH Key Authentication

Generate an SSH key pair and copy the public key to your server before disabling password authentication entirely.

3. Disable Root SSH Login

Once your sudo user is confirmed working, set PermitRootLogin no in your SSH daemon config to remove the most common brute-force target.

4. Change the Default SSH Port (Optional but Helpful)

Moving off port 22 won’t stop a targeted attacker, but it dramatically cuts down noise from automated scanning bots hitting your logs.

5. Set Up a Firewall

Use ufw, firewalld, or your distribution’s default firewall tool to allow only the ports you actually need — typically SSH, HTTP and HTTPS to start.

6. Install fail2ban

fail2ban automatically bans IPs after repeated failed login attempts, adding a meaningful layer of protection against brute-force attacks with minimal setup.

Server Management add-on: If this list sounds like more than you want to manage yourself, our Standard and Fully Managed plans handle hardening, patching and firewall configuration for you.

7. Apply System Updates

Run your package manager’s update command immediately — a freshly imaged server can already be behind on security patches by the time it’s provisioned.

8. Set Up Automatic Security Updates

Configure unattended upgrades (or your distro’s equivalent) for security patches specifically, while keeping major version upgrades manual.

9. Configure Monitoring

Even basic uptime and resource monitoring will tell you about problems before your users do. Our Basic Monitoring add-on covers this if you don’t want to self-host a monitoring stack.

10. Set Up Backups

None of the above matters if a bad deploy or disk failure wipes your data with no way back. Add off-server backup before you put anything important on the box — see our Cloud Backup plans.

None of these steps take long individually, but skipping them is how a server that was fine for six months suddenly isn’t.

A safer SSH change sequence

  1. Read your distribution’s SSH documentation and check configuration include files. A setting in a drop-in may override what you edited in the main file.
  2. Create a named administrator and confirm that sudo -v succeeds from a new login before restricting root.
  3. Install the public key only; never copy a private key onto the server. Confirm key login in a second terminal before disabling password login. Consider PAM and keyboard-interactive authentication requirements rather than assuming one option disables all interactive methods.
  4. Run sudo sshd -t to validate syntax. Inspect effective settings with sudo sshd -T; Match blocks can require connection-specific checks. Validation does not prove the network will admit your next login.
  5. Allow the actual SSH port in the host firewall and any provider firewall before enabling restrictive rules. Keep recovery access available.
  6. Reload the appropriate SSH service for your distribution, then open a fresh session and test both sign-in and sudo. Do not close the original session until the new one works.

Service names vary: some systems use ssh, others sshd. If validation or the second login fails, use the still-open session or recovery console to restore the previous configuration. Changing port 22 is not a substitute for authentication, patching or access control.

Record the handover

Save the OS version, administrator name, authentication method, allowed inbound ports, update policy, backup location and recovery-console procedure in a secure operations record. Do not place private keys or recovery codes in public tickets. Check security-update reboot requirements and schedule downtime rather than assuming a package update alone patches a running kernel.