How to Secure a Linux VPS Without Locking Yourself Out

Secure a Linux VPS in stages: establish recovery access, verify a non-root administrator and SSH key in a second session, then restrict authentication and inbound ports. Keep the original session open until the new login works after every change. A firewall or SSH change without a recovery path can turn a routine configuration edit into an outage.

Scope and recovery prerequisites

This checklist targets Ubuntu and Debian installations using OpenSSH, systemd and UFW. Provider images can differ. It is documentation-checked, not a report of a runtime test on every distribution release. If the server uses another firewall manager, centralized identity or SSH multi-factor authentication, adapt the procedure instead of layering contradictory settings over it.

Confirm access to the provider’s console or rescue environment and how to recover a failed network login. Verify the account credentials needed there.
Record the actual SSH port, public addresses and existing host/provider firewall rules. Do not change the SSH port during this hardening pass.
Back up /etc/ssh/sshd_config and its included configuration directory to a protected, timestamped location. Keep the original session open.
Identify a named administrator account with working sudo access. Create one using your distribution’s account procedure if necessary, then verify it before proceeding.

# On the VPS: inspect before changing anything
cat /etc/os-release
sudo ss -lntp
sudo systemctl status ssh
sudo /usr/sbin/sshd -t

1. Prove key login in a separate session

Generate a passphrase-protected key on your own computer, or use an appropriate existing key. Keep the private key there. Install only the public key into the administrator’s authorized_keys using a trusted session. Check ownership and permissions; never make the home or SSH directory globally writable to fix access.

# On a Linux/macOS client; substitute the real account, host and port
ssh-keygen -t ed25519
ssh-copy-id -p 22 admin@YOUR_SERVER_IP
ssh -p 22 -o PreferredAuthentications=publickey -o PasswordAuthentication=no admin@YOUR_SERVER_IP

Do not overwrite an existing key when ssh-keygen prompts. Windows OpenSSH can generate and use keys, but ssh-copy-id may be unavailable; append the public key through the existing trusted session instead. In the new session, run sudo -v and verify that administrative commands work. Do not disable root or password login before this succeeds.

2. Inspect the effective SSH policy

OpenSSH normally uses the first obtained value for a setting. Included files and Match blocks matter; adding a file named 99-hardening.conf does not guarantee an override. Inspect /etc/ssh/sshd_config and all included snippets, then change the configuration that actually controls your administrator connection.

# Intended policy for key-only administration without PAM-based SSH MFA
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Do not apply that keyboard-interactive setting to an MFA design that requires it. Before activation, inspect the effective policy for your connection with sshd -T -C using the real user, client address and host; this is especially important when Match rules exist. Confirm that required authorized-key and authentication-method settings are still valid.

# On the VPS, after editing the applicable configuration
sudo /usr/sbin/sshd -t
# Continue only if the validation command succeeds
sudo systemctl reload ssh

Open another fresh key-authenticated connection and test sudo again. A surviving old connection does not prove that new logins work. If validation or login fails, use the still-open session or console to restore the exact configuration you changed, validate it and reload again.

3. Permit SSH before enabling a host firewall

Inspect the existing firewall first. The example below applies to a simple UFW-managed VPS with SSH actually listening on TCP 22. Replace that port if yours differs. Add rules for required application traffic before enabling a default inbound restriction, and check the provider firewall as a separate layer.

# On the VPS; review each command before continuing
sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

Review both IPv4 and IPv6 access if the VPS has both. A source-IP restriction is useful only when the administrator’s address is stable or another trusted access route exists. Container port publishing and other firewall tooling need their own exposure audit; the example is not a universal policy for a container host.

What if a new SSH connection stops working?

Recover through the retained session or provider console
Observed failure	Check	Targeted recovery
Timeout	Correct address/port, host rules and provider firewall	Permit the actual SSH port through the layer blocking it; do not reset unrelated rules.
Connection refused	SSH service status and listening socket	Correct invalid configuration, validate and start/reload the service as appropriate.
Permission denied	User, key, file permissions and effective authentication policy	Restore the changed authentication configuration or repair the intended public-key entry.
Host-key warning	Whether the server was rebuilt or its identity changed	Verify the fingerprint through a trusted channel before changing the client’s known-host entry.

4. Maintain the server after the first login

Apply distribution security updates with a recovery plan, monitor failed services and free space, and review exposed services after deployments. Store application secrets outside public repositories. Keep off-server backups and prove a restore; an operating system snapshot alone does not establish application-consistent database recovery.

Continue with first steps on a VPS and memory monitoring. When choosing VPS hosting, include console recovery and administration responsibilities in the decision, alongside CPU and memory.