HardStacked →

SSH · self-inflicted outages

Locked out of your own server: the five classic SSH lock-outs

2026-07-19 · HardStacked · 6 min read

You changed one line in sshd_config, typed exit, and now your own server refuses to let you in. No attacker, no malware. Just you, one config file, and a door that locks from the inside.

Almost every lock-out we have seen is one of the same five mistakes. Each has a habit that makes it survivable, and there is one safety net that covers them all.

1. Password login off, key never tested

The advice is everywhere, and it is good advice: PasswordAuthentication no. But it silently assumes your key is installed and actually works. If authorized_keys never landed on the server, has the wrong permissions, or holds a truncated paste of your public key, you just removed the only door you could open.

The habit

Prove key login from a second terminal before turning passwords off, and keep your first session open. If the new connection gets in without a password prompt, you may proceed.

2. The firewall came up before the allow rule

$ sudo ufw default deny incoming $ sudo ufw enable ← port 22 is now closed. Your session survives; the next one won't.

This one is cruel because it looks fine. Your current SSH connection is already established, so the firewall does not cut it. Everything works until you disconnect, and then nothing does.

The habit

sudo ufw allow ssh before sudo ufw enable, always in that order. Then open a new terminal and connect again before you trust it.

3. fail2ban banned you

You install fail2ban to keep the bots out. Then one morning you typo your passphrase a few times, and the ban hammer does not care that it is you. Default jails ban after roughly five failures. If you connect from behind a shared or carrier-grade NAT address, someone else's failures can count toward your ban too.

The habit

Put your own address in ignoreip in jail.local. Already banned? Bans expire (often 10 minutes to an hour). From another address or the provider console: fail2ban-client set sshd unbanip YOUR.IP.

4. The port change that systemd ignored

You set Port 2222 in sshd_config, opened 2222 in the firewall, restarted SSH. And the server still answers on 22, or on nothing you expected. On Ubuntu 22.10 and newer, SSH is socket-activated: systemd's ssh.socket decides what port is listened on, and depending on the release it can silently override what sshd_config says.

The habit

After any port change, ask the kernel what is really listening, and believe it over any config file:

$ sudo ss -tlnp | grep sshd LISTEN 0 4096 *:22 users:(("sshd",...)) ← the truth, whatever the config says

5. The typo that explodes weeks later

An invalid sshd_config does not kill the running daemon; it keeps serving with the old config. The failure waits for the next restart. Often that is a reboot weeks later, when you no longer remember having edited anything, and sshd simply refuses to start.

The habit

Validate after every edit. No output means valid:

$ sudo sshd -t $ sudo systemctl reload ssh ← reload, not restart, when possible

The four survival rules

  1. Never close your working session until the new one is proven. Established connections survive an sshd restart; that open terminal is your lifeline.
  2. Test every change with a fresh connection from a second terminal.
  3. sshd -t before, reload after.
  4. Find your provider's rescue console today, before you need it. Every serious host has one (web console, VNC, recovery mode). It is not SSH, so it still works when SSH does not. Log into it once now, so the day it matters is not the day you learn it.

Already locked out?

Take a breath: if the server is up, your data is fine, and the way back in is the rescue console mentioned above. It gives you a keyboard on the machine as if you were standing in front of it. Log in there, undo or fix the change, run sshd -t, restart SSH, and test a real SSH connection before you log out of the console.

The deeper lesson

Every risky change should have its way back prepared before the change is applied. Editing by hand leaves that discipline up to you, at 2 a.m., on a production box.

That is the principle HardVps is built on: it captures the original before touching any file, every fix reverts byte-exact (verified by SHA-256), and the one fix that could lock you out is opt-in behind an explicit warning. In our full test cycle on a live VPS, SSH stayed up through apply and revert.

See what HardVps does →

On a Raspberry Pi? Start free with audit-pi, our open-source security audit.