Recover access with the rescue console
Locking yourself out of SSH is stressful, but it is almost always fixable. A VPS gives you a second way in: a web-based console from your control panel. That console does not depend on SSH or your firewall rules, so you can use it to undo the change that caused the lockout.
Before you begin
- Access to your LightServe control panel, where the console is available for your VPS.
- The root password or console login for the server. If you do not have it, contact LightServe support via chat or email before you do anything else.
- A calm moment. Most lockouts come from one edited file or one firewall rule.
Step 1: Open the console and log in
In the control panel, open the console for your VPS. It shows the server's login prompt directly, just like a monitor plugged into the machine. Log in as root or as your sudo user. If the console is blank, click inside it and press Enter.
vps login: alex
Password:
alex@vps:~$
Once you have a shell, check the basics. First, is SSH running at all?
sudo systemctl status ssh --no-pager
● ssh.service - OpenBSD Secure Shell server
Active: active (running) since Sat 2026-10-31 08:02:11 UTC
On Ubuntu 24.04 the service is called ssh, and it is socket-activated, which means systemd also watches the SSH port.
Step 2: Check the SSH configuration for mistakes
A single typo in the SSH config can stop the service from starting, or stop your key from working. The built-in syntax check runs without output when everything is fine:
sudo sshd -t
If there is a problem, it prints the file and line number, such as /etc/ssh/sshd_config:42: Bad configuration option. Open the file, fix that line, and check again. To see the settings that actually apply, including drop-in files, run:
sudo sshd -T | grep -Ei 'port|passwordauthentication|pubkeyauthentication'
port 22
passwordauthentication no
pubkeyauthentication yes
Step 3: Restore a working configuration
If you changed the port or disabled passwords, restore a known-good setting. Keep your SSH key login enabled, and set the port back to 22 while you recover. After editing, validate the file and restart SSH:
sudo nano /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart ssh.service
Ubuntu 24.04 also reads extra files in /etc/ssh/sshd_config.d/. A setting there can override the main file, so check that folder too:
ls -l /etc/ssh/sshd_config.d/
sudo cat /etc/ssh/sshd_config.d/*.conf
Step 4: Check the firewall
If you tightened the firewall, you may have blocked SSH itself. Make sure the SSH rule exists before anything else. The OpenSSH profile allows port 22:
sudo ufw status verbose
sudo ufw allow OpenSSH
If you changed the SSH port, allow the new port instead, such as sudo ufw allow 2222/tcp. Then try SSH again from your own computer.
Step 5: Check your authorized key
If the server rejects your key, the most likely cause is file permissions. The home folder, .ssh, and authorized_keys must not be writable by others. Check them and fix any that are wrong:
ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Step 6: Test from a second session
Before you close the console, open a new SSH session from your computer and log in. Only then close the console session. If the new login fails, keep the console open and go back to the step that changed last.
sshd_config in future, keep one SSH session open. If the new settings break, that open session lets you fix them without the console.sudo sshd -t first. A broken config can stop SSH from starting at all, which is exactly the lockout you are trying to escape.Troubleshooting
- The console login does not accept your password. Reset the root or console password from the control panel. If you cannot reset it, contact LightServe support via chat or email and verify your account.
- SSH is running and the config is valid, but the port is still closed. Check whether SSH is listening with
sudo ss -tlnp | grep ssh. On Ubuntu 24.04 a changed port also needs the socket override, so the simplest recovery is to return to port 22. - Your key is rejected even though it is correct. The key may be in the wrong account's
authorized_keys, or the file may have Windows line endings. Compare the key with the one on your computer. - Password login is disabled and no key works. Use the console to add your public key to
~/.ssh/authorized_keys, then set the permissions from Step 5.
Next steps
Once you are back in, make a note of what caused the lockout and test changes one at a time. For stronger protection, read the guide on adding two-factor authentication to SSH, and check your open ports as described in the guide on open ports and listening services.
Something not working? Chat or email our support team and we will help you get unstuck.
Contact support