Servers & VPS

Secure SSH on Your VPS: Configuration and Best Practices

Learn how to configure SSH securely on your VPS with key-based authentication, a custom port, and brute-force protection.

Closeup of many cables with blue wires plugged in modern switch with similar adapters on blurred background in modern studio

Securing SSH on a VPS means replacing password authentication with cryptographic keys, changing the default port, disabling direct root access, and installing brute-force protection. With these four steps, the risk of an SSH intrusion drops dramatically.

This guide covers each adjustment with exact commands. It assumes you already know how to connect to your VPS via SSH, but no prior hardening experience is required.

Why Default SSH Configuration Is an Immediate Risk

The moment a VPS is provisioned with a public IP, bots begin scanning port 22 within minutes. Each login attempt with generic credentials (root/root, admin/123456) is an automated brute-force attack.

An unhardened VPS can receive thousands of login attempts per day. The good news: blocking them does not require advanced expertise — it requires following a concrete checklist.

Step 1: Key-Based Authentication (No Password)

This is the single most important change. An ED25519 or 4096-bit RSA key is impossible to guess by brute force.

Generate the key pair on your local machine

# ED25519 (recommended — shorter and equally secure)
ssh-keygen -t ed25519 -C "[email protected]"

# RSA 4096 bits (alternative for older system compatibility)
ssh-keygen -t rsa -b 4096 -C "[email protected]"

Keep the private key (~/.ssh/id_ed25519) in a safe place. Never upload it to any server.

Copy the public key to the VPS

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

If ssh-copy-id is not available, manually append the contents of id_ed25519.pub to ~/.ssh/authorized_keys on the server.

Verify the key works before disabling passwords

ssh -i ~/.ssh/id_ed25519 user@VPS_IP

If you log in without being asked for a password, the key pair is correctly installed. Only then proceed to the next step.

Step 2: Edit /etc/ssh/sshd_config

This file controls SSH server behavior. Open it with a text editor:

sudo nano /etc/ssh/sshd_config

Apply the following changes (or verify they are already set correctly):

Directive Secure Value Why
Port A number between 1024–65535 (e.g. 2244) Avoids mass scanning of port 22
PermitRootLogin no Root should never access directly via SSH
PasswordAuthentication no Forces key use; eliminates password attacks
PubkeyAuthentication yes Enables public key authentication
AuthorizedKeysFile .ssh/authorized_keys Standard path for authorized keys
MaxAuthTries 3 Limits attempts per connection
LoginGraceTime 30 Seconds to authenticate before disconnecting
X11Forwarding no Disables GUI forwarding if not needed

Save the file and reload the SSH service:

sudo systemctl reload sshd

Important: keep your current session open and open a second session on the new port before closing the first one. If there is a configuration error, you will have time to fix it without getting locked out.

Step 3: Firewall — Allow Only the New SSH Port

The port change in sshd_config only works if the firewall also allows the new port and blocks port 22.

With UFW (Ubuntu/Debian)

sudo ufw allow 2244/tcp
sudo ufw deny 22/tcp
sudo ufw reload

With firewalld (CentOS/Rocky/AlmaLinux)

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

For deeper coverage of VPS firewall configuration, browse our VPS server guides for OS-specific firewall tutorials.

Step 4: Install Fail2ban for Brute-Force Protection

Even after disabling passwords, Fail2ban protects against aggressive port scans and other authentication attempts that generate log noise.

# Ubuntu/Debian
sudo apt install fail2ban -y

# CentOS/Rocky/AlmaLinux
sudo dnf install fail2ban -y

Create a local SSH configuration file:

sudo nano /etc/fail2ban/jail.d/sshd.conf
[sshd]
enabled  = true
port     = 2244
maxretry = 3
bantime  = 3600
findtime = 600
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

With this configuration, any IP that fails 3 times within 10 minutes is banned for 1 hour.

Additional Best Practices

  • Use an unprivileged user with sudo: create a dedicated user for daily work and grant them sudo access. Do not work as root.
  • Passphrase on the private key: add a password to your local private key to protect it if someone gains access to your machine.
  • AllowUsers: in sshd_config you can restrict SSH access to specific users only: AllowUsers youruser.
  • IP whitelist when possible: if your IP is static, allow SSH only from that IP in the firewall. It is the strongest protection available.
  • Keep SSH updated: regularly apply security updates for the openssh-server package.

Looking for a managed VPS that includes security hardening from day one? The team at elenlace.com can help you find the right solution for your level of technical experience.

Key Takeaways

  • Key-based authentication (ED25519 or RSA 4096) is the most important change — it eliminates password attacks entirely.
  • Change the SSH port from the default 22 to reduce noise from automated scans.
  • Disable PermitRootLogin and PasswordAuthentication in sshd_config.
  • Configure the firewall to allow only the new SSH port and block port 22.
  • Install Fail2ban to automatically ban IPs with repeated failed access attempts.
  • Always verify the new configuration works before closing your active session.

FAQ

Is changing the SSH port enough to be secure?

No. Changing the port reduces noise from mass scans, but it is not a security measure on its own — an attacker can scan all ports. Key-based authentication and disabling password login are the changes that actually protect access.

Can I use ED25519 instead of RSA?

Yes, and it is the recommended option. ED25519 produces shorter keys, operates faster, and offers security equivalent to 4096-bit RSA. It is compatible with OpenSSH 6.5+ (2014), so it works on any modern server.

What do I do if I get locked out of my VPS after changing the SSH config?

Most VPS providers offer an emergency console (VNC or KVM over IP) accessible from the control panel. From there you can edit sshd_config, fix the error, and reload the service without needing SSH access.

Does Fail2ban still work even if I disabled PasswordAuthentication?

Yes. Even without password attempts to fail, Fail2ban also blocks aggressive port scans and errors in key negotiation. It also serves as a useful defense-in-depth layer if you enable other services on the same VPS in the future.

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

Useful resources

Other providers and guides worth comparing:

← All