A spare key so you never get locked out of your machine (rescue user)

Think for a moment about what would happen if tomorrow you could not get into one of your machines. The SSH key was on the laptop of someone who has left; a technician changed the Administrator password and nobody wrote it down; a change to the SSH configuration went wrong and the door closed with you outside. The machine keeps running and the website stays up, but you are no longer in charge of it, and in AWS nobody opens it for you: there is no "I forgot my password" and no support team that logs in on your behalf. Lightsail gets you out of trouble on Linux (its web console logs in with a temporary key), but on Windows only if nobody ever touched the password, and on EC2 the official route involves stopping the machine. When that does not work, what remains is hours of snapshots and new machines, at the worst possible moment. This guide shows you how to leave an emergency door ready before you need it, built so that only you can use it.

Step by step

1. Decide what you want the emergency door to be like

   A badly made rescue user is worse than none: a password written down in a shared document is the first door an attacker tries. What we want: that it has no password, that it only accepts certificates signed by you and short-lived, and if possible that it only accepts connections from a fixed IP of yours. That way, even if someone knows the user name, there is nothing for them to try.

2. Create a certificate authority (once only)

   On your computer, not on the machine:

   ssh-keygen -t ed25519 -f ca_rescate -C "CA de rescate"

   Keep ca_rescate (the private key) somewhere safe: a password manager or an encrypted disk. Never copy it to the machines. The ca_rescate.pub file is the one that will go to each machine.

3. Prepare the Linux machine

   Log in over SSH as usual (you still can) and, with sudo:

   sudo useradd -m -s /bin/bash -c "Usuario de rescate" rescate
   sudo usermod -p "*" rescate          # sin contraseña valida, sin bloquear
   echo "rescate ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/90-rescate
   sudo chmod 440 /etc/sudoers.d/90-rescate
   sudo cp ca_rescate.pub /etc/ssh/ca_rescate.pub
   echo 'from="TU.IP.FIJA" rescate' | sudo tee /etc/ssh/principales_rescate

   And in /etc/ssh/sshd_config (or a file in /etc/ssh/sshd_config.d/), at the top:

   TrustedUserCAKeys /etc/ssh/ca_rescate.pub
   AuthorizedPrincipalsFile /etc/ssh/principales_rescate

   Check and reload: sudo sshd -t && sudo systemctl reload ssh. The rescate user has no password and only accepts certificates from your CA, and only from your IP if you set from=.

4. Prepare the Windows machine

   Windows Server 2019 and later include OpenSSH as an optional feature. In PowerShell as administrator: Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0, start the sshd service and open port 22 in the Windows firewall and in the Lightsail or EC2 one (only for your IP). Create the user with a long random password that you do not write down anywhere (do not create it without a password: by default Windows blocks network access for accounts with a blank password, and OpenSSH counts as network access), add it to Administrators, copy ca_rescate.pub and the principals file to C:\ProgramData\ssh\ and, in the sshd_config in that same folder, put the same two lines as on Linux (with the paths as __PROGRAMDATA__/ssh/). A detail that costs hours: Windows OpenSSH rejects authentication files that other users can read, so remove permission inheritance from them and leave only Administrators and SYSTEM: icacls FICHERO /inheritance:r /grant Administrators:F /grant SYSTEM:F. Restart sshd. If you want PowerShell instead of cmd when you log in, set the registry key HKLM:\SOFTWARE\OpenSSH\DefaultShell to powershell.exe.

5. Test the door before you need it

   Generate a normal key and sign it with the CA for five minutes:

   ssh-keygen -t ed25519 -f temporal -N ""
   ssh-keygen -s ca_rescate -I "prueba" -n rescate -V +5m temporal.pub
   ssh -i temporal rescate@IP.DE.LA.MAQUINA sudo -n true && echo OK

   If you see OK, the door works. After five minutes the certificate stops being valid on its own: there is nothing to revoke or delete.

6. If you have already lost access: what to do once the door is open

   Log in with a new certificate and fix the administrator: on Linux sudo passwd ubuntu (or whichever user it is) or add your new public key to its ~/.ssh/authorized_keys; on Windows net user Administrator NUEVA-CONTRASEÑA. If the account was locked, sudo passwd -u usuario or net user usuario /active:yes.

7. And if you had no emergency door

   Linux on Lightsail: the Lightsail web console logs in with a temporary key, so from there you can do what the previous step describes. Windows on Lightsail: the console gives you the Administrator password only if nobody changed it; otherwise you will have to create a snapshot and a new machine. EC2: the official AWSSupport-ResetAccess procedure in Systems Manager resets the password or the key by stopping and starting the machine.

8. And if there is no snapshot either

   This is the end of the chain and it is worth looking at it squarely: if you cannot get in and no copy of the machine exists, everything inside it is lost. The application, the database, the files, the configurations. AWS cannot log in for you or recover what was never copied, and there is no technical service to call. That is why the emergency door and automatic snapshots are not two options to choose between: they are the two things that separate an hour-long scare from losing a client's business.

What can go wrong