Skip to main content
Harden SSH in stages: establish a working administrator account and SSH key first, then restrict login methods. The commands below target Debian and Ubuntu.
Keep your existing SSH session open and have the VNC console available. Test a second, independent login after each change. Do not disable your only working way to sign in.

​
1. Update OpenSSH

Use the distribution’s packages; security fixes may be backported without changing the upstream version number. Follow Update SSHD.

​
2. Create and test an administrator account

On the VPS, create an account if you do not already have one. Replace adminuser throughout this guide with your chosen username:
In a new terminal on your computer, connect as that user and verify administrative access:
Keep the original session open until both commands work.

​
3. Configure SSH key authentication

On your computer, generate a key if you do not already have one. Protect it with a passphrase and do not overwrite an existing key you still use:
ssh-copy-id copies the public key; keep the private key on your computer. If your client does not include this tool, use its public-key installation instructions. See the OpenSSH key-generation manual. Test a fresh connection that permits only public-key authentication:
A prompt for the private key’s passphrase is normal. Confirm that sudo -v also works in this new session.

​
4. Restrict login methods

Back up /etc/ssh/sshd_config and any files you will edit in /etc/ssh/sshd_config.d/. Inspect the existing configuration before adding settings: included snippets can take precedence over the main file. For a key-only setup without PAM-based MFA, configure:
Do this only after the non-root administrator and key login work. These settings do not disable the account’s password for console login or sudo. Check syntax and the effective configuration:
If you use Match blocks, effective settings can differ by user and connection. Resolve unexpected values before proceeding. OpenSSH generally uses the first value found for each setting; see Ubuntu’s OpenSSH configuration guide and the OpenSSH configuration reference. If validation passes, reload SSH on Debian/Ubuntu:
Open another new connection and verify key login and sudo before closing your original session.

​
5. Apply firewall rules before enabling the firewall

Allow the actual SSH TCP port before enabling UFW. Port 22 is the default; replace it if you changed it. Follow the UFW setup guide, including its reconnect test. A custom port can reduce automated login noise, but it is not a substitute for authentication or access controls. Port changes also require matching firewall, client, and sometimes ssh.socket configuration. They are optional and are not part of the key-only procedure above.

​
6. Monitor access and consider additional controls

Inspect recent SSH events on Debian/Ubuntu:
Fail2Ban can add temporary bans for repeated failed logins. Configure its SSH port and log backend to match the server; do not assume /var/log/auth.log exists on a journal-only installation. For MFA, use a complete procedure for your distribution and authentication provider. Enabling keyboard-interactive authentication alone does not require a second factor. An MFA configuration must combine the intended methods and enroll all affected users; it also differs from the key-only settings above. See OpenSSH AuthenticationMethods.

​
If a new login fails

Keep the existing session open, review the SSH journal, and restore the configuration files you changed. Validate with sshd -t before reloading. If all SSH access is lost, use the VNC console to repair the configuration.
Last modified on September 30, 2026