What I Saw in My New VPS Logs: Automated Attacks and How to Secure Your Server

Description and use

Massive brute‑force SSH attempts were observed on a new VPS. Enabling key authentication, disabling root password login, and installing fail2ban reduced log noise and CPU usage.

Problem

Automated brute‑force login attempts from the internet are flooding the SSH daemon of a newly deployed VPS, causing CPU load and exposing the server to potential compromise.

Outcome

The server’s SSH daemon stopped accepting password logins, root access was locked, and fail2ban began blocking repeated failed attempts, resulting in a significant reduction of authentication log noise and CPU load.

Workflow

• 1. Connect to the server and view /var/log/auth.log to identify brute‑force activity.
• 2. Run grep sshd /var/log/auth.log to filter SSH daemon entries.
• 3. Generate an SSH key pair and copy the public key to the server’s ~/.ssh/authorized_keys for the desired user.
• 4. Test key authentication in a new terminal session before making changes.
• 5. Edit /etc/ssh/sshd_config to set PasswordAuthentication no and PermitRootLogin no.
• 6. Restart the SSH service (systemctl restart sshd).
• 7. Install fail2ban (apt install fail2ban) and configure it to monitor sshd logs.
• 8. Verify that failed attempts are blocked and logs quiet down.

Evidence

Every single minute, automated scripts from all over the world were trying to log in. They guessed common usernames like root, admin, test, and demo, running through endless password combinations.

Source

To stop the brute-force attempts from hammering your CPU, you should harden the server configuration. First, set up SSH key authentication and disable password login entirely for the root user.

Source

Installing a tool like fail2ban will also help by automatically blocking IP addresses that fail multiple login attempts.

Source

Always make sure your SSH key actually works in a new terminal session before you disable passwords.

Source