Secure SSH Server Configuration on Ubuntu VPS: Complete Hardening

Why SSH Server Hardening Matters for VPS Hosting

Your SSH server is the front door to your VPS. Default configurations work fine for testing, but production hosting demands stricter security measures.

Attackers constantly scan for weak SSH setups. This makes server hardening essential for any Hostperl VPS deployment.

This tutorial covers practical SSH hardening steps that protect your Ubuntu VPS without breaking legitimate access. You'll configure secure protocols, disable risky features, and implement access controls that stop common attacks.

Check Your Current SSH Configuration

Start by examining your existing SSH setup. The main configuration file lives at /etc/ssh/sshd_config.

Before making changes, create a backup:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo systemctl status ssh
ss -tlnp | grep :22

The status command shows if SSH is running properly. The last command confirms which port SSH currently uses.

Check recent login attempts in your logs:

sudo journalctl -u ssh --since "1 hour ago" | grep "authentication failure"

You'll likely see multiple failed login attempts, especially if your VPS has been online for a while. These attempts show exactly why hardening matters.

Change the Default SSH Port

Moving SSH away from port 22 reduces automated attack traffic significantly. Choose a port above 1024 to avoid conflicts with system services:

sudo nano /etc/ssh/sshd_config

Find the line #Port 22 and change it to:

Port 2222

Pick any unused port between 1024-65535. Avoid common ports like 3389 (RDP) or 8080 (HTTP alternate).

After changing the port, update your firewall rules before restarting SSH:

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo systemctl restart ssh

Critical: Test the new port in a separate terminal session before closing your current connection. Connect using ssh -p 2222 username@your-server-ip to verify access works.

Disable Root Login and Password Authentication

Root login via SSH creates unnecessary security risks. Disable it completely and force users to elevate privileges after login:

sudo nano /etc/ssh/sshd_config

Set these directives:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

These changes disable password-based logins entirely. They force key-based authentication instead.

Before applying these settings, ensure you have SSH keys properly configured for your user account.

If you haven't set up keys yet, our guide on VPS security configuration covers key management in detail.

Test your key authentication before restarting SSH:

ssh -p 2222 -i ~/.ssh/your-private-key username@your-server-ip

Configure Protocol and Cipher Settings

Modern SSH should use only secure protocols and encryption methods. Add these lines to your sshd_config:

Protocol 2
HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group14-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-256,hmac-sha2-512

These settings disable older, vulnerable protocols and enforce strong encryption. The configuration prioritizes ChaCha20 and AES-GCM ciphers, which provide excellent security and performance.

If you manage client sites or need compatibility with older systems, you might need to keep some legacy options. Test connectivity with your most restrictive client systems before removing all compatibility options.

Set Up User Access Controls

Limit SSH access to specific users and groups rather than allowing system-wide access:

sudo nano /etc/ssh/sshd_config

Add user restrictions:

AllowUsers username1 username2
DenyUsers baduser malicious-account
AllowGroups ssh-users sudo

Create a dedicated SSH users group for better organization:

sudo groupadd ssh-users
sudo usermod -a -G ssh-users your-username

You can also restrict access by IP address or network range:

AllowUsers username@192.168.1.0/24
AllowUsers admin@203.0.113.0/24

This approach works well for agencies managing multiple client sites from fixed office locations.

Configure Connection Limits and Timeouts

Prevent connection abuse and reduce resource consumption with these timeout settings:

MaxAuthTries 3
MaxStartups 5:30:10
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

These settings limit failed login attempts to 3. They restrict concurrent connections during peak times and automatically disconnect idle sessions after 10 minutes (300 seconds × 2).

For hosting environments with multiple users, consider slightly higher limits:

MaxStartups 10:60:20

Enable and Configure SSH Logging

Detailed logging helps track access attempts and troubleshoot connection issues:

sudo nano /etc/ssh/sshd_config

Set logging options:

LogLevel VERBOSE
SyslogFacility AUTH

Create a dedicated log monitoring script to track unusual activity:

sudo nano /usr/local/bin/ssh-monitor.sh

#!/bin/bash
tail -f /var/log/auth.log | grep --line-buffered "sshd" | while read line; do
    echo "$(date): $line" >> /var/log/ssh-activity.log
    if echo "$line" | grep -q "authentication failure"; then
        echo "Failed SSH login attempt: $line" | mail -s "SSH Alert" admin@yourdomain.com
    fi
done

Make the script executable and run it as a service for continuous monitoring:

sudo chmod +x /usr/local/bin/ssh-monitor.sh

Test and Apply Your Secure SSH Server Configuration

Before restarting SSH with your changes, test the configuration for syntax errors:

sudo sshd -t

If the test passes without errors, restart SSH:

sudo systemctl restart ssh
sudo systemctl status ssh

Verify the service started successfully and is listening on your new port:

ss -tlnp | grep :2222

Test connectivity from another machine or terminal session:

ssh -p 2222 username@your-server-ip

Keep your original terminal session open until you confirm the new settings work properly.

Monitor and Maintain SSH Security

Regular monitoring ensures your SSH hardening remains effective. Check authentication logs weekly:

sudo grep "authentication failure" /var/log/auth.log | tail -20

Update SSH packages when security patches become available:

sudo apt update
sudo apt list --upgradable | grep ssh
sudo apt upgrade openssh-server

Consider implementing fail2ban for automatic IP blocking after multiple failed attempts. Our tutorial on UFW firewall configuration covers additional network security layers.

For production hosting environments, document your SSH configuration changes. Maintain consistent settings across multiple servers.

Configuration management tools like Ansible can standardize these settings across your infrastructure.

Frequently Asked Questions

Should I disable SSH completely and use a web-based console instead?

Web consoles are useful for emergencies, but SSH remains the most efficient way to manage servers. Properly hardened SSH is more secure than most web interfaces. Keep SSH enabled but follow the security practices in this guide.

What happens if I lock myself out after changing SSH settings?

Most VPS providers offer console access through their control panels. Use this to restore your backup configuration file and restart SSH. Always test changes in a separate session before closing your primary connection.

How often should I rotate SSH host keys?

SSH host keys don't need regular rotation unless you suspect compromise. Focus on keeping SSH software updated and monitoring access logs for unusual activity instead.

Can I use SSH hardening with shared hosting accounts?

Shared hosting typically doesn't provide SSH access or the ability to modify SSH configurations. These hardening techniques apply to VPS and dedicated servers where you have root access.

Should I enable two-factor authentication for SSH?

Two-factor authentication adds security but can complicate automated deployments and scripts. For interactive logins, consider implementing 2FA. For automated access, properly secured SSH keys provide adequate protection.