Why your VPS logs show SSH login attempts (and when to worry)
Fresh servers get automated login attempts within hours, thousands per week. Why it's background noise with keys-only auth, and the three patterns that aren't.
Random login attempts in a fresh VPS’s SSH logs are normal: automated bots scan the entire internet around the clock, trying common usernames and leaked passwords against every reachable machine. It isn’t personal and it isn’t a breach. With password login disabled and key-only authentication on, those attempts are background noise: the log lines are them failing.
What you’re seeing, and why it starts so fast
Provision a server, wait an hour, read journalctl -u ssh, and there they are: Failed password for root, Invalid user admin, from IPs you’ve never heard of. Nobody found you; scanners sweep entire IP ranges continuously, so a new machine gets its first knocks within hours of existing. The volume is larger than most people guess: one 2025 academic study logged 12,224 SSH connection attempts against a single decoy server in seven days of observation. We provision cloud servers for a living and see the same thing on every fresh machine, including the fun variant where a cloud provider recycles an IP address and your brand-new server inherits a stream of bots already interested in its previous life.
The two settings that decide whether this matters
The bots are trying passwords. The whole game is making passwords not a thing that works:
- Key-only authentication. Your SSH key can’t be guessed by a dictionary. In
/etc/ssh/sshd_config:PasswordAuthentication no(most cloud images with an SSH key selected at creation ship this way. Verify, don’t assume; the safe way to set it yourself takes one drop-in file). - No direct root login.
PermitRootLogin no(orprohibit-passwordat minimum). Studies of these attacks consistently findrootis the most-tried username by far. Make the most-attacked door not exist.
With those two set, a failed-password line in your log is a bot wasting its time. Optional extras (fail2ban to thin the log noise, a non-standard port to reduce it further, a firewall limiting SSH to your own IP) are comfort and hygiene, not the load-bearing wall. What they mostly buy you is quieter logs, so real anomalies stand out.
If you run an AI agent on the box, the stakes are higher
An agent’s VPS holds more than a hobby site does: model API keys, the agent’s memory and files, its messaging credentials. The SSH noise doesn’t change, but the cost of a lucky bot does. The same discipline covers it (keys only, no root, updates applied), plus the agent-specific rule that deserves its own guide: the Gateway never faces the public internet. SSH should be the only listening port. (On Everpod’s OpenClaw pod there is nothing on the server for you to log in to at all.) The fuller picture lives in our safe-hosting checklist.
When log lines do deserve attention
Three patterns are worth a closer look, none of them the random noise: an Accepted line at a time you didn’t log in (check last and your provider’s console access log); attempts against a real username you actually created (targeted, not sprayed); and a sudden order-of-magnitude spike from one IP (worth a firewall rule even though it still can’t guess a key). Everything else is the internet being the internet.