Secure SSH on VPS: Configuration Best Practices

To configure secure SSH on a VPS, the bare minimum is: disable root login, use public-key authentication, and change the default port. Without those three measures, any Internet-facing server will face brute-force attacks within minutes of going live.

This guide covers each step with exact commands for Linux servers (Ubuntu/Debian or CentOS/AlmaLinux). By the end you will have hardened SSH access that resists the most common automated attacks.

Why unconfigured SSH is the top attack vector

SSH listens on port 22 by default. Bots continuously scan the Internet looking for that open port and, once found, launch dictionary attacks against the root user. A freshly provisioned VPS can receive thousands of login attempts within its first few hours.

The problem is not the SSH protocol itself — it is cryptographically sound. The problem is the factory configuration, designed for convenience rather than production use.

Step 1: Generate an SSH key pair (on your local machine)

Before touching the server, create the key pair on your computer:

# ED25519 is modern and compact; RSA 4096 also works fine
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/my_vps_ed25519

Choose a strong passphrase when prompted. The private key never leaves your machine — only the public (.pub) key goes to the server.

Copy the public key to the VPS:

ssh-copy-id -i ~/.ssh/my_vps_ed25519.pub user@VPS_IP

Verify you can log in with the key before making any other changes. If something goes wrong later you will have an open session to fix it.

Step 2: Edit /etc/ssh/sshd_config

Open the SSH daemon configuration file:

sudo nano /etc/ssh/sshd_config

Apply these key directives:

Save the file and check for syntax errors before restarting:

sudo sshd -t

If the command returns nothing, the syntax is correct. Restart the service:

# Ubuntu/Debian
sudo systemctl restart ssh

# CentOS/AlmaLinux
sudo systemctl restart sshd

Important: open a second terminal and connect on the new port before closing the current session. This confirms everything works without locking yourself out.

Step 3: Update the firewall for the new port

With UFW (Ubuntu/Debian):

sudo ufw allow 2222/tcp comment "Custom SSH"
sudo ufw deny 22/tcp
sudo ufw reload

With firewalld (CentOS/AlmaLinux):

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Remember to also update rules in your VPS provider's network firewall panel if one exists — this is common on DigitalOcean, Hetzner, Linode, and similar platforms.

Step 4: Extra protection with Fail2Ban

Even with password authentication disabled, installing Fail2Ban adds a defense layer that bans IPs with too many failed attempts:

# Ubuntu/Debian
sudo apt install fail2ban -y

# CentOS/AlmaLinux
sudo dnf install fail2ban -y

Create a local config file so your changes survive package upgrades:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit /etc/fail2ban/jail.local and adjust the [sshd] section:

[sshd]
enabled  = true
port     = 2222
maxretry = 5
bantime  = 1h
findtime = 10m

sudo systemctl enable --now fail2ban

Any IP that fails 5 times in 10 minutes gets blocked for 1 hour automatically.

Additional best practices

• Rotate your keys periodically: if you suspect a private key was compromised, generate a new pair and remove the old key from ~/.ssh/authorized_keys.
• Use SSH Agent Forwarding with caution: only enable ForwardAgent yes when you genuinely need to jump between servers; otherwise leave it off.
• Keep OpenSSH updated: run sudo apt update && sudo apt upgrade openssh-server regularly. Vulnerabilities like CVE-2024-6387 (regreSSHion) get patched quickly — but only if you update.
• Review authentication logs: sudo journalctl -u ssh --since today or /var/log/auth.log to spot anomalous patterns.
• Consider TOTP-based 2FA: the libpam-google-authenticator module adds a second factor without breaking the public-key flow.

Managing multiple servers? Browse the full VPS server guide library for articles on firewalls, monitoring, and performance tuning.

Key takeaways

• Disabling root login and password authentication are the two changes with the biggest immediate impact.
• ED25519 or RSA-4096 keys make authentication cryptographically resistant to brute force.
• Changing from port 22 to a custom port dramatically reduces log noise from automated bots.
• Fail2Ban auto-bans malicious IPs even if residual attack vectors remain.
• Always verify the new configuration works in a second terminal before closing your active session.

Need help securing your server or looking for a VPS configured with best practices from day one? Reach out to us at elenlace.com — our team will guide you through every step.

FAQ

Is changing the SSH port mandatory?

Not mandatory, but strongly recommended. Switching from port 22 to a custom port eliminates automated bot traffic that only scans the standard port. On test servers it may be optional; on production systems it is always worthwhile.

Can I use RSA keys instead of ED25519?

Yes. RSA with 4096 bits is perfectly secure today. ED25519 is preferred because keys are shorter, operations are faster, and the algorithm is more modern. If your SSH client is very old and does not support ED25519, use RSA-4096.

What do I do if I lock myself out due to a configuration error?

Most VPS providers offer an emergency console from the web panel (KVM or VNC). Use it to fix sshd_config and restart the service. This is exactly why you should always keep the original session open while testing changes.

Does Fail2Ban help if I disable password authentication?

Yes, in other ways. Even without passwords making direct brute force useless, Fail2Ban can block username enumeration attempts, version-scanning probes, or attacks on other services on the same server (Apache, FTP, etc.). Installing it always adds value.

Prefer it done for you? El Enlace handles hosting and professional web development.

Further reading

Other providers and guides worth comparing:

• Hostinger
• HubSpot
• IONOS