Why it is urgent
A server exposed to the Internet receives automated login attempts within hours of going live. These attacks do not target your project in particular: they scan all IPv4 addresses looking for a weak password.
1. SSH key authentication
Generate a key pair on your workstation, then place the public key in the server's ~/.ssh/authorized_keys. Test the key-based connection before disabling passwords — this is the classic mistake that gets you locked out.
2. Disable root login and password login
In /etc/ssh/sshd_config:
PermitRootLogin no PasswordAuthentication no
Then systemctl restart ssh. Keep the VNC console open during the operation.
3. A non-privileged user for each person
Each administrator must have their own account, with sudo. Shared accounts make any investigation impossible after an incident.
4. Automatic security updates
apt install unattended-upgrades dpkg-reconfigure --priority=low unattended-upgrades
5. Minimal firewall
Open only what is needed: SSH, HTTP, HTTPS. Everything else should be closed by default, including database ports, which should never be exposed publicly.
6. Brute-force protection
Install fail2ban: it temporarily bans addresses that repeatedly fail authentication. With key-based authentication, it becomes a second barrier rather than the only defense.
7. Deny root connections to services
Database, administration panels, cache interfaces: each must have its own user, with strictly the necessary rights. A compromised site must not be able to become a compromised server.
8. Monitor and back up
An untested backup is not a backup. Restore one once to verify that it works. Check /var/log/auth.log regularly: intrusion attempts are visible there before they succeed.
What we do on our side
The infrastructure is protected (KVM isolation, DDoS protection, filtered network). Operating system security, however, is your responsibility: that is the very principle of a VPS. Our support team is happy to help if you are unsure about a configuration.
