Set up SSH keys on Ubuntu and verify access before disabling passwords

An SSH key deployment has two separate goals: prove that the intended administrator can log in, then remove authentication paths you no longer need. Reversing that order is a common cause of VPS lockouts. This procedure keeps an existing session and a browser-console recovery route available while you test a new, independent connection.

Create a dedicated, passphrase-protected key

Use a separate key for the administrative role rather than distributing the same private key to a whole team. The private file stays on the workstation; only the file ending in .pub belongs on the server. A passphrase protects the stored private key if the workstation or its backups are exposed.

umask 077
ssh-keygen -t ed25519 -a 64 \
  -f ~/.ssh/plenty_vps_ed25519 \
  -C 'admin-workstation'
ssh-keygen -lf ~/.ssh/plenty_vps_ed25519.pub

Choose a passphrase at the prompt. The fingerprint identifies this public key; it is different from the server host-key fingerprint. If the target filename already exists, do not overwrite it to follow an example. Choose a new filename or use the existing key only after confirming its purpose. An SSH agent can cache an unlocked key for a session without copying it to the server.

Verify the server identity and install the public key

Before accepting a new host key, compare its fingerprint through a trusted channel such as the authenticated server console. A hostname resolving to the expected IP is useful, but it does not by itself authenticate the remote SSH service. Do not suppress host-key verification to make an error disappear.

ssh-copy-id -i ~/.ssh/plenty_vps_ed25519.pub \
  vpsuser@server.example.com

If the SSH port is not 22, add the appropriate -p option. On the server, the authorized_keys file must belong to the intended account and must not be writable by unrelated users. Keep .ssh private to that account. A public key installed under root does not authorize vpsuser, and the reverse is also true.

Test a new connection without connection sharing

A reused SSH connection can appear to prove that a key works even though authentication happened earlier. Start an independent connection that explicitly selects the key and disallows password fallback. Keep the original terminal open throughout the test.

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  -i ~/.ssh/plenty_vps_ed25519 \
  vpsuser@server.example.com

Once connected, run id and sudo -v to confirm both the account identity and the administration rights you need. If the connection fails, inspect the client with ssh -v and the server with sudo journalctl -u ssh.service -n 80 --no-pager. Look for the offered key, accepted key and account name instead of posting complete diagnostic output containing internal details.

Inspect effective configuration before changing authentication

Ubuntu loads configuration snippets before many settings in the main file. Most sshd directives use the first value found, so appending a contradictory setting at the end may have no effect. Match blocks can also change settings for a specific user or source address.

sudo sshd -T -C user=vpsuser,host=server.example.com,addr=203.0.113.10 \
  | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
sudo sshd -t

Replace the documentation address 203.0.113.10 with the actual client address when testing Match behavior. For a conventional key-based administrator, PubkeyAuthentication yes and PasswordAuthentication no are common goals after key access is proven. Review keyboard-interactive authentication separately: it may implement a password path or an intentional MFA step. Do not remove a required second factor as a side effect of following a key-only example.

Apply the smallest change and verify the result

Back up the relevant configuration and edit a clearly named snippet through sudoedit. Validate with sshd -t before reloading. Authentication changes normally apply to new sessions after the service reload; listener and port changes can additionally involve Ubuntu socket activation and are covered in our separate port-change guide.

sudo sshd -t && sudo systemctl reload ssh.service
sudo systemctl status ssh.service --no-pager
sudo journalctl -u ssh.service -n 40 --no-pager

Repeat the independent key-login test after the reload. Do not close the original session until the second login works. If it fails, use the retained session or console to restore the edited file, validate it and reload again. The successful outcome is a new login using the intended key and account, not simply a successful systemctl command.

Maintain access as people and devices change

• Keep an inventory linking each authorized public key to an owner and purpose.
• Remove a departing administrator's key and revoke access to shared accounts.
• Replace exposed keys rather than only changing the private-key passphrase.
• Keep console access and a tested administrator recovery process available.

A key is an authentication credential, not a backup strategy or an application-security policy. Continue patching the SSH server, restrict administrative access where practical and avoid sharing the Control Panel login just to grant someone access to one VPS.

Primary documentation

• Ubuntu OpenSSH server
• OpenSSH server configuration
• OpenSSH client configuration