TroubleshootingWritten by GLWS14 min readUbuntu 24.04 LTS / AlmaLinux 9
Commands run on your server unless a section says otherwise. Replace example usernames, addresses and paths with your own values. Keep a working session open when changing remote access.

Stay calm and find your console

SSH rejecting you does not mean the server is down. Most lockouts come from a firewall rule that blocks SSH, a changed SSH setting, a missing key or a forgotten password. Your server's virtual console works without the network, so you can repair these.

Open the console or VNC screen offered by your provider's control panel. Log in there with a username and password. If the account only has an SSH key and no password, the console login will fail, and you will need the boot-menu method further down.

From your computer: see why the connection fails
ssh -v deploy@YOUR_SERVER
ping YOUR_SERVER
Prevention is better than recovery. Give your admin account a password you store safely, even if you normally use keys, and test the console login before you need it.

Fix an SSH configuration mistake

Once logged in at the console, check the configuration for errors and see why the service is not working. Then undo your last change and reload. A broken file stops sshd from starting after a restart.

At the console
sudo sshd -t
sudo systemctl status ssh sshd --no-pager 2>/dev/null
sudo journalctl -u ssh -u sshd --since "30 minutes ago" --no-pager | tail -n 40
sudo ls -l /etc/ssh/sshd_config.d/

Fix a firewall that blocks SSH

A new firewall policy can block your own port. At the console, look at the rules and allow the SSH port. If you are unsure which rule is wrong, switch the firewall off temporarily, log in over SSH to repair it, and turn it back on.

Use the port actually configured in sshd, not an assumed default. At the console, the following command reads the effective SSH port even when there is no SSH_CONNECTION variable.

Ubuntu (UFW)
sudo ufw status numbered
SSH_PORT=$(sudo /usr/sbin/sshd -T | awk '/^port /{print $2;exit}')
sudo ufw allow "$SSH_PORT/tcp"
# or temporarily: sudo ufw disable
AlmaLinux (firewalld)
sudo firewall-cmd --list-all
SSH_PORT=$(sudo /usr/sbin/sshd -T | awk '/^port /{print $2;exit}')
sudo firewall-cmd --permanent --add-port="$SSH_PORT/tcp"
sudo firewall-cmd --reload

Fix a key or permission problem

SSH ignores keys when the account's home folder or .ssh directory is writable by other users. Check the owner and modes, and confirm the public key is present in authorized_keys.

At the console, as the affected user
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
wc -l ~/.ssh/authorized_keys

Reset a forgotten password from the console

If you can still log in as another account with sudo, set a new password for the affected user. Otherwise continue with the boot-menu method.

As an account with sudo
sudo passwd deploy

Ubuntu: reset a password from recovery mode

Restart the server from the control panel and open the console quickly. Hold Shift (BIOS boot) or press Esc (UEFI boot) as it starts to reach the GRUB menu. Choose Advanced options, then the recovery mode entry, and then root shell. Whether the menu appears depends on your console and boot timeout, so contact support if it does not.

In the recovery root shell
mount -o remount,rw /
passwd deploy
sync
reboot -f

AlmaLinux: reset a password from the boot menu

Restart the server and press e on the first GRUB entry to edit it. Add rd.break to the end of the line that begins with linux, then press Control-X to boot. The system stops in an emergency shell before the real root is mounted. Mount it writable, change the password, and tell SELinux to relabel files on the next boot so logins work.

In the emergency shell
mount -o remount,rw /sysroot
chroot /sysroot
passwd deploy
touch /.autorelabel
exit
exit
The relabel makes the first boot slower. Wait until it finishes before logging in.

When console access also fails

If the console does not respond, or the server does not boot, contact your provider's support with the server name and what you changed. As a last resort, rebuild the server from your own backup. A restore you have practised before is much faster than one you attempt in a hurry, which is why a tested backup is worth more than any recovery trick.

Official documentation

These upstream references provide more detail on the commands and workflows in this guide.