SSH keys or passwords?
On a NeoHeberg VPS, the first SSH login uses root and the password shown in the dashboard. That password grants full control and is the most scanned target on the internet. SSH keys remove that weak point, provided you keep a fallback.
How a key pair works
A key pair has a private key, which stays on your computer, and a public key, copied to ~/.ssh/authorized_keys on the server. At login, the server sends a challenge that only the private key can sign. No secret crosses the network, and the server stores nothing that allows login as you.
| Criterion | Password | SSH key |
|---|---|---|
| Brute force | depends on length | impossible without the private key |
| Entry on a fake site | possible | the key is never typed |
| Copy to another machine | trivial | requires the private file |
| Loss | reset from the dashboard | keep a backup key |
Create and install the key
Generate an Ed25519 key, shorter and stronger than RSA for normal use:
ssh-keygen -t ed25519 -a 100 -C "main-laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@YOUR_IPV6The first command creates ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). The second adds it to the server and sets permissions: 700 on ~/.ssh, 600 on authorized_keys. Test without closing your current session:
ssh -o PreferredAuthentications=publickey root@YOUR_IPV6Passphrase, agent and hardware key
A passphrase encrypts the private key on disk. Without it, a stolen file is enough to log in; with it, the thief must also guess the passphrase. ssh-agent keeps the unlocked key for the session so you do not retype it for every command. A FIDO2 key (ssh-keygen -t ed25519-sk) also requires physical confirmation at each login, protecting you even if the file is copied.
Always keep a second way in: another key in authorized_keys, an encrypted private-key copy elsewhere, or the dashboard console. The console still accepts the root password when SSH password authentication is disabled.
Disable password login
Keep one session open and validate the configuration in another before cutting anything. Use a drop-in file instead of editing the main configuration:
sudo tee /etc/ssh/sshd_config.d/10-keys-only.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sudo sshd -t
sudo systemctl reload sshsshd -t checks the syntax without applying it. PermitRootLogin prohibit-password allows root with a key and rejects the password; create a sudo user if you prefer to forbid root over SSH.
Check and troubleshoot
sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin'shows the effective configuration.ssh -v root@YOUR_IPV6shows which authentication method is attempted.journalctl -u ssh -n 50explains a server-side rejection.
If you lock yourself out, open the noVNC console from the dashboard: you remain root on the machine. Remove the faulty line from authorized_keys to revoke a key, then reload SSH.
Advertisement
Was this article helpful?
Read next
- Server security checklistAccess, network, data and monitoring: an ordered checklist with a verification command for each item.
- Understanding firewallsUnderstand inbound and outbound policies, then configure UFW on Debian without cutting SSH.
- Apply security updatesUpdate Debian, understand the shared kernel and automate security fixes without surprise reboots.