SSH hardening on Ubuntu should make administrative access harder to abuse while keeping recovery practical. A strong key is only part of that work: the server must enforce the intended authentication policy, trusted administrators must still reach it, and a lost laptop must not become a permanent credential.
This guide provides a staged SSH security checklist for an Ubuntu VPS. Check the documentation for your installed release and test changes on a non-production server first. Cloud images, managed access services, and existing two-factor authentication can change which settings are appropriate.
1. Establish a recovery path before changing SSH
Before editing anything, open your provider's console or documented rescue facility and confirm you can use it. Knowing that a console button exists is different from having working recovery access when your network connection fails.
Keep your existing SSH session open, record the current working connection details, and save copies of the configuration files you will edit. Record how to restore those files through the console. An existing session is useful during testing, but it is not a substitute for recovery access.
Make authentication changes, firewall changes, and account cleanup separate steps. If you change all three together and a login fails, you have several possible causes and a much harder rollback. Choose a quiet maintenance window and tell other administrators what is being tested.
2. Give each administrator a named account and key
Use individual administrator accounts with only the privileges their work requires. Confirm that the intended account can complete the necessary sudo operations before restricting root access. Keep application and deployment identities separate from personal administration.
Ubuntu's user management documentation explains privilege management and an important offboarding detail: locking a user's password does not necessarily stop SSH access through an existing authorized key.
Generate an administrator's key on their own trusted workstation. An Ed25519 key is a practical option where organizational policy and client compatibility allow it. Choose a new filename to avoid overwriting an existing key, and protect the private key with a strong passphrase. Upload only the public key to the intended server account. The OpenSSH key-generation manual describes key types, passphrases, and public-key files.
Record the owner, purpose, and fingerprint of each approved key. A small inventory makes a lost-device response much easier than trying to identify anonymous keys during an incident.
3. Verify server identity and test a fresh connection
Check the server's host-key fingerprint through a trusted, independent channel, such as your authenticated provider console, before accepting a new host key. Investigate an unexpected change instead of clearing the warning automatically. Server rebuilds can explain a change, but that explanation still needs verification.
Test the intended administrator account from a second terminal while leaving the recovery session open. If your client shares SSH connections, an ordinary second terminal may reuse an already authenticated connection. Use a fresh transport for the check:
ssh -o ControlPath=none admin@example-serverReplace admin and example-server with your real account and host; use your normal identity file, port, or jump-host options where required. The OpenSSH client configuration manual documents connection sharing and host-key checking. After signing in, verify the expected privilege escalation and file-transfer workflow.
4. Inspect the effective Ubuntu SSH configuration
Ubuntu normally includes /etc/ssh/sshd_config.d/*.conf near the beginning of /etc/ssh/sshd_config. For most directives, the first obtained value wins. A setting appended to the main file can therefore lose to an earlier snippet. Review existing snippets, including provider-managed configuration, before adding your own. See Ubuntu's OpenSSH server guide.
Use these checks on the server to validate syntax and inspect the configuration that would be loaded:
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -TThese commands do not prove that the running service has loaded a change or that a firewall allows connections. They check configuration, not the whole access path.
Where Match rules apply, inspect the result for the actual user and connection context using sshd -T -C. Include the relevant source address, destination address, port, and host context as appropriate. The sshd manual documents those test parameters. A global configuration listing alone can miss a user-specific exception.
5. Choose an authentication policy deliberately
A server that intentionally uses public keys alone needs different settings from one that requires a key plus a one-time code. Treat the following as a review table, not a configuration file to paste blindly:
| Setting | What to review | Check before applying |
|---|---|---|
PubkeyAuthentication | Allow the approved key-based login workflow. | The correct key works for every required account. |
PasswordAuthentication | Disable password authentication when the replacement is ready. | Administrators and automation have tested alternatives. |
KbdInteractiveAuthentication | Review password prompts and MFA requirements separately. | Disabling it will not remove a required second-factor method. |
AuthenticationMethods | Express required combinations when using multiple factors. | Test the complete chain, including expected failures. |
PermitRootLogin | Consider no once named administration works. | Recovery and required privileged tasks remain possible. |
AllowUsers or AllowGroups | Limit eligible accounts when an explicit list is manageable. | Include approved deployment and backup identities. |
Consult the Ubuntu 24.04 SSH configuration reference, or the local man sshd_config for your installed release, for exact directive behavior.
Setting PasswordAuthentication no alone does not establish a complete key-only policy: keyboard-interactive authentication may still provide another route. Conversely, switching keyboard-interactive off can break PAM-based MFA. Ubuntu's TOTP/HOTP guide uses public-key authentication together with keyboard-interactive authentication and requires users to enroll before enforcement. Preserve the PAM settings that your chosen design needs.
6. Restrict network access without breaking recovery
Where practical, allow SSH only from known management networks or a controlled VPN. Account for both the provider firewall and the host firewall, plus IPv4 and IPv6 paths. Confirm which source address the server actually sees; a laptop's private Wi-Fi address may not be the address reaching the VPS.
Prepare the required allow rules before tightening access, and retain the web ports and other services the server needs. Ubuntu's firewall documentation covers source-specific rules and UFW's dry-run option. Adapt examples to your real port and network rather than enabling a generic ruleset during a remote session.
A changing home or mobile IP needs an operational plan. A stable management VPN can be easier to maintain than repeatedly widening an allowlist. Document how someone will restore access if that VPN is unavailable.
7. Apply one change, then test allowed and denied access
After reviewing the intended change, run the syntax check again. Resolve every error before applying it. Follow your Ubuntu release's service instructions; the Ubuntu OpenSSH guide documents restarting ssh.service after successful validation. Keep the console available throughout.
Complete the following checks after each stage:
- A fresh connection succeeds for the intended administrator.
- The required key and any configured second factor are actually used.
- A login without the required authentication method is rejected.
- Direct root login is rejected if that is your intended policy.
- Deployment, SFTP, and backup jobs still work with their approved identities.
- The allowed management network connects and an excluded test network cannot.
Use a small number of controlled tests against your own server. Keep a record of the result and any relevant authentication log entry. If the test fails, restore the specific change through your recovery path, validate again, and investigate before continuing.
8. Keep access review part of server maintenance
Assign responsibility for removing departed administrators, retiring old device keys, and checking access after image rebuilds or provisioning changes. If a key is suspected to be compromised, revoke its authorization promptly and investigate existing sessions and other access paths.
Review this SSH checklist alongside the broader VPS security baseline and self-hosted control panel security checklist. A hosting panel's login policy and the underlying operating system's SSH policy both need attention. Use the Core Panel documentation to understand the product's documented setup and current limitations before planning a deployment.
Frequently asked questions
Should I change the default SSH port?
A different port may reduce routine scanning noise, but it does not replace strong authentication or access restrictions. Treat a port change as a separate network change and test firewall, client, and service configuration together.
Can I disable SSH passwords immediately after copying a key?
First verify a fresh login with the intended key, required privileges, automation, and recovery access. A copied public-key file alone does not demonstrate that the complete login path works.
Why does my sshd_config change appear to be ignored?
Check earlier included snippets, applicable Match rules, and whether the service has loaded the updated configuration. Compare effective settings with the actual connection context before making more edits.
Does an SSH key passphrase replace server-enforced MFA?
No. A passphrase protects the private key locally. The server does not independently verify that passphrase as a second authentication step. If policy requires MFA, configure and test a supported server-enforced design.
