SSH Hardening in 2026: Use Keys Without Locking Yourself Out

Scope and recovery access

This guide is reviewed for late 2026 and uses Ubuntu Server with OpenSSH as the example. Service names and configuration ownership differ on other distributions and control panels. Before editing, verify that the provider’s recovery console works, keep the current SSH session open and confirm a non-root administrator can use sudo. Record the actual SSH port and every administrator who needs access.

Create a dedicated client key

Run this on your own computer, choose an unused filename and set a passphrase when prompted. The OpenSSH key manual describes key generation; environments with cryptographic policy restrictions should use their approved key type.

ssh-keygen -t ed25519 -f ~/.ssh/kiava_admin_2026
ssh-copy-id -i ~/.ssh/kiava_admin_2026.pub -p YOUR_SSH_PORT admin@YOUR_SERVER

Replace the capitalized placeholders before running the second command. Only the public .pub key goes to the server. Test the private key from a second terminal with the same user and port, and confirm sudo works there.

Review the effective policy

Ubuntu’s SSH guide recommends validating configuration before applying it. Back up the configuration and inspect include files and Match blocks. These commands check syntax and display effective defaults:

sudo sshd -t
sudo sshd -T

Use sshd’s connection-specific test options when Match rules apply. Read the authentication directives before changing them. For a tested, key-only setup, PasswordAuthentication no and PermitRootLogin no may be appropriate. Do not disable keyboard-interactive authentication if your MFA method requires it.

Apply one controlled change

After a successful syntax check, reload the Ubuntu service with sudo systemctl reload ssh.service. Keep the original session open and establish a completely new connection; an already-open shell does not prove new logins work. Test both the regular administrator and your documented recovery route. Check file ownership and authorized_keys permissions if key login fails.

Rollback and acceptance

If the fresh connection fails, restore the saved configuration through the open session or provider console, validate it and reload again. Stop rather than stacking firewall and authentication changes in the same step. Record the successful user, port, authentication method and recovery owner. Use our firewall rollout guide for the separate network step or ask Kiava IT services to review a managed environment.