Confirm ownership of the server and use its authorized console or rescue feature. Record the last successful login and recent firewall, account or SSH changes. Keep console credentials private and identify the correct machine before changing anything.

1. Log in through the independent console and check the server address, route and link state. Confirm the IP matches the service record and no recent change removed the route.
2. Inspect the SSH listener with ss -lntp and the correct service status. If the daemon failed, run sshd -t and read its journal or authentication log.
3. Compare host firewall rules and provider firewall/security-group rules with the real SSH port and your current source address. Repair a scoped rule rather than disabling all filtering.
4. For authentication failures, inspect the intended account, authorized key, ownership, expiry and effective sshd Match/Allow rules. Restore the last known-good configuration when a recent policy change caused the lockout.
5. Validate the configuration, reload the actual service and open a new remote connection. Test sudo access before ending the console session.

Open the server console using your authorised management account. On Ubuntu, the service is commonly ssh.service; other distributions commonly use sshd.service. Substitute the actual unit and port before running these read-only checks.

sudo systemctl status ssh.service --no-pager -l
sudo ss -ltnp 'sport = :22'
sudo journalctl -u ssh.service --since '-15 minutes' --no-pager -n 60

Read the result: A running service with a listener suggests that the next checks are its bind address, network policy and authentication log. A failed service needs its recorded error examined before a restart. If socket activation manages SSH, inspect the related socket unit as well.

Keep the console connected while correcting only the identified cause. Do not flush the entire firewall or replace the SSH configuration with a generic template. After recovery, open a new external SSH session and verify the intended authentication method works.

Verify the new fingerprint through the trusted console first. A change can be legitimate after rebuilding a host, but it can also mean you reached the wrong machine. Do not blindly remove the warning.

Confirm both reachability and authentication from the intended network. Verify the repaired rule is persistent and does not open unrelated ports. Record the cause and establish a tested recovery account or console procedure for future changes.

If the console cannot boot or mount the system, switch to a controlled rescue workflow and inspect disks before making filesystem repairs. A timeout and a Permission denied response indicate different layers. Do not reinstall the OS, regenerate every host key or delete firewall rules merely because SSH is unavailable.

• Testing SSH configuration before reloading the service
• Restricting Ubuntu firewall access without locking out SSH
• Managing firewalld zones and permitted services
• Inspecting an unbootable Linux server from rescue mode

• Ubuntu: Openssh Server
• man.openbsd.org: Sshd
• Ubuntu: Firewalls

• systemd systemctl manual, published by Debian
• iproute2 ss manual, published by Debian
• systemd journalctl manual, published by Debian