nokyc.hostSecure access first
1. Use a new SSH key for this server
Generate a dedicated key pair (an Ed25519 key is a good default) and use it only for this server. Reusing a key you have uploaded to code hosting sites or other servers creates a unique fingerprint that links them together.
2. Disable password logins
Once your key works, set PasswordAuthentication no in the SSH server configuration and restart the SSH service. Passwords can be brute-forced; keys realistically cannot.
3. Stop logging in as root
Create a normal user with sudo rights, log in as that user, and set PermitRootLogin no. Attackers target the root account by default.
Keep your existing SSH session open while you change SSH settings, and test a new login in a second window before closing it. A typo can lock you out; if it does, most providers offer a web console in the control panel.
Lock down the network
4. Enable a firewall
Allow only the ports you actually use. With ufw that means allowing SSH (and, for example, ports 80 and 443 for a web server), setting the default to deny incoming traffic, then enabling it.
5. Remove services you do not need
List listening services and remove or disable anything you did not install on purpose. Every open service is something that can be attacked or that can reveal information about the server.
6. Add brute-force protection
A tool such as fail2ban temporarily blocks IP addresses that repeatedly fail to log in. With key-only SSH it is less critical, but it also reduces log noise.
Keep it updated
7. Turn on automatic security updates
On Debian and Ubuntu, the unattended-upgrades package installs security updates automatically. Unpatched software is the most common way servers are compromised.
8. Reboot for kernel updates
Kernel updates only take effect after a reboot. Schedule regular reboots or check periodically whether one is pending.
Control what the server records
9. Limit log retention
By default, system logs record every SSH login and its source IP address. Set a sensible retention limit in journald (for example with MaxRetentionSec) so logs do not accumulate indefinitely. Keep enough to investigate problems; delete the rest.
10. Anonymize web server logs
If you run a website, configure the web server to omit visitor IP addresses from access logs or to truncate them, unless you genuinely need them for security.
Your provider's own logging is a separate matter, covered in no-logs hosting explained.
Keep your habits private
11. Always connect the same private way
Connect over the same VPN or Tor setup you used to buy the server, every time, including control panel logins. One direct connection from your home IP links the server to you.
12. Keep identities separate
- Use a hostname, usernames, and passwords that you do not use anywhere else.
- Do not log in to personal accounts from the server.
- Do not copy personal files, dotfiles, or configuration that contain your name or email.
Verify your setup
Once you have worked through the checklist, confirm the changes actually took effect:
- Listening services: run ss -tulpn and make sure only the services you expect are listening.
- Effective SSH settings: run sshd -T and check that passwordauthentication and permitrootlogin are both set to no.
- Firewall: run ufw status verbose (or the equivalent for your firewall) and confirm the default incoming policy is deny.
- Updates: check that the unattended-upgrades service is enabled and has run recently.
- External view: from a different machine, scan your server's public IP to confirm only the intended ports are reachable.
Back up without leaking your identity
Backups are easy to overlook, and a backup stored in your personal cloud account links the server straight back to you.
- Encrypt backups on the server before they leave it, with a key you keep offline.
- Store them with a storage provider you signed up for the same private way as the VPS, not a personal account.
- Test restoring from a backup at least once. An untested backup is not a backup.
A note on disk encryption
Encrypting a VPS disk protects data if the provider's storage is removed or reused, but it cannot protect you from the provider itself. The provider controls the hypervisor, and a running virtual machine keeps encryption keys in memory the host can access. If you need protection from the provider, the answer is careful provider choice (see the no-KYC VPS list) and encrypting sensitive data before it ever reaches the server.
Frequently asked questions
What is the first thing to do on a new VPS?
Set up SSH key authentication with a new key, disable password logins and root login, and enable a firewall. Then turn on automatic security updates.
Does disk encryption protect my VPS from the hosting provider?
Not fully. The provider controls the hypervisor and can access a running machine's memory, including encryption keys. Encryption mainly protects data at rest on removed or reused storage.
Should I change the SSH port?
Changing the port reduces automated login attempts and log noise, but it is not real security. Key-only authentication and disabling root login matter far more.