SSH keys or passwords?

3 min read07 November 2026

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:

Bash
ssh-keygen -t ed25519 -a 100 -C "main-laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@YOUR_IPV6

The 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:

Bash
ssh -o PreferredAuthentications=publickey root@YOUR_IPV6

Passphrase, 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:

Bash
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 ssh

sshd -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_IPV6 shows which authentication method is attempted.
  • journalctl -u ssh -n 50 explains 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