Secure SSH access to your VPS and preserve a recovery route
SSH is often the front door to a Linux VPS. A useful access policy protects that door while keeping a tested way back inside. The safest change sequence proves a replacement works before removing the existing access method.
The practical takeaway
Verify the server identity, use individual accounts and protected keys, test each configuration change in a second session, and keep a separately controlled recovery procedure.
Start with an access inventory and a recovery route
Before editing SSH, list every legitimate way into the server: administrator accounts, deployment jobs, backup clients, monitoring agents and any third-party maintainer. Record which identity each one uses and whether it needs a shell, file transfer or a restricted automated action. A forgotten deployment key can remain useful to someone long after a person leaves the project.
Confirm how access would be recovered if a firewall rule or authentication change failed. A provider console or recovery environment may be relevant, but do not assume a particular facility is included or already configured. Ask the team to confirm the available route and who is authorised to use it. Keep the procedure in a private location that remains reachable when this VPS is unavailable.
Keep the current working SSH session open while making a planned change. Use another terminal for new connection tests. An existing session continuing to work proves little about whether a fresh connection can authenticate, so closing the first terminal is the final step rather than the test itself.
Verify the host, then establish individual identities
The server host key identifies the machine; your user key authenticates you to it. Compare the host-key fingerprint with a value obtained through an independently trusted channel before accepting a first connection. If a previously known fingerprint changes, establish whether a rebuild or planned key rotation explains it. Deleting the saved fingerprint just to remove the warning skips that identity check.
Give each administrator a named account and an individual SSH key. Protect the private key on the administrator device, preferably with a passphrase and an appropriate local agent or a login process that uses a hardware security key. Install only the public key on the server. Check the owner and permissions of the account home, SSH directory and authorised-key file using the documentation for the installed operating system.
For a two-person project, record which key belongs to each person and when it was authorised. Test a fresh connection as that named user and verify the intended administrative elevation separately. Sharing one private key or one routine root login makes departure, investigation and selective revocation unnecessarily difficult.
Change authentication in a sequence you can verify
| Control | Decision to make | Evidence before tightening |
|---|---|---|
| Public-key authentication | Which named accounts and keys are accepted? | A fresh key-based login for every required administrator |
| Password authentication | Is it still required by an approved workflow? | Replacement access and recovery have both been tested |
| Keyboard-interactive authentication | Does an MFA or PAM policy depend on it? | The complete intended authentication sequence succeeds |
| Direct root access | Can daily administration use named accounts? | The required elevation path works from a new session |
Treat PasswordAuthentication and KbdInteractiveAuthentication as separate decisions. Disabling password authentication alone does not describe every interactive authentication path, while disabling keyboard-interactive access indiscriminately can break an intended MFA setup. Read the effective policy for your installed OpenSSH version and test the entire login journey, including any second factor.
OpenSSH configuration can include additional files and conditional Match sections. A line appended at the bottom does not necessarily override an earlier applicable value. Validate syntax before applying a change; on the documented Ubuntu workflow, sudo sshd -t performs that check. Inspect the effective configuration for the relevant connection context and follow the operating system service-management instructions. Syntax validation does not prove network reachability or successful authentication.
Limit exposure without confusing obscurity with protection
If administrators connect from predictable networks, consider restricting the administrative entry point to those networks or an appropriately managed private access path. Account for travelling staff, changing residential addresses and automated clients before enforcing a restriction. Check the rule from a genuinely new connection, and retain the agreed recovery route throughout the change.
Changing the SSH port may reduce background scanning noise, but it does not replace strong authentication or timely updates. Avoid unnecessary forwarding and agent forwarding in everyday sessions. A deployment job that only transfers files should not automatically inherit the same capabilities as a human administrator. Scope each automation identity to the task its owner can explain.
Keep OpenSSH and the operating system maintained through their supported update process. Review authentication failures alongside successful logins, source networks and planned maintenance. A large count of failed public attempts is a reason to assess exposure; it is not proof that a particular account was successfully accessed.
Finish with a repeatable access review
- A new session verifies the expected host fingerprint and authenticates with the intended identity.
- Each administrator can perform approved work using the required elevation method.
- Deployment and backup jobs still succeed with their own restricted identities.
- The previous access method is removed only after replacement and recovery checks pass.
- A departing person has their account access and individual keys reviewed promptly.
Repeat the review after adding a maintainer, rebuilding a server or changing your authentication policy. Store the approved access inventory without copying private keys into project notes or support tickets. When requesting help, provide the server reference, operating system, approximate failure time and exact non-secret error. A clear failure description is more useful than sharing control of an administrator credential.
