Introduction

Losing SSH access to a dedicated server can be stressful, especially when the server is running websites, databases, applications, or production workloads.

An SSH failure does not necessarily mean that the server is down or that the operating system needs to be reinstalled. In many cases, the problem is caused by a blocked SSH port, an SSH configuration error, failed authentication, a stopped SSH service, disk exhaustion, or a network configuration problem.

This guide explains how to diagnose and recover SSH access to a Linux dedicated server without unnecessarily reinstalling the operating system.

⚠️

Important: Do not reinstall the operating system as a first response. If the server contains important data, stop and verify that you have a valid backup before performing any destructive recovery operation.

The examples below focus primarily on Ubuntu Server. Commands may differ on other Linux distributions.

What Causes SSH Access to Stop Working?

SSH access can fail for several different reasons. Common causes include:

Problem	Typical symptom
Firewall blocking SSH	Connection timeout
SSH service stopped	Connection refused
Incorrect SSH configuration	Connection refused or service fails to start
Invalid SSH key	`Permission denied (publickey)`
Incorrect permissions	Authentication rejected
Fail2Ban/CrowdSec ban	Connection timeout or blocked connection
Wrong SSH port	Connection timeout or refused
Disk full	SSH service or login may fail
Network configuration problem	Timeout or no route to host
Server not booting	No network or SSH response

The first step is to identify which category your problem belongs to.

Step 1: Identify the SSH Error

Before changing anything on the server, test the connection from your local computer.

Bash

ssh username@SERVER_IP

If SSH uses a custom port:

Bash

ssh -p 2222 username@SERVER_IP

(Replace username, SERVER_IP, and 2222 with your actual values.)

Pay attention to the error message.

Connection timed out

Plaintext

ssh: connect to host SERVER_IP port 22: Connection timed out

Possible causes include: Firewall rules, Network problems, Incorrect IP address, Server not fully booted, or SSH listening on another port.

Connection refused

Plaintext

ssh: connect to host SERVER_IP port 22: Connection refused

The server may be reachable, but nothing is accepting connections on that port. Possible causes: SSH service stopped, SSH is listening on another port, SSH configuration error, or Host firewall rejecting the connection.

Permission denied

Plaintext

Permission denied (publickey)

This normally indicates an authentication problem rather than a network problem. Possible causes: Wrong private key, Public key missing from authorized_keys, Incorrect file ownership, Incorrect SSH permissions, Wrong username, or SSH authentication configuration.

Step 2: Check Whether the Server Is Reachable

From your local machine, test the server IP:.

Bash

 ping SERVER_IP

A failed ping does not automatically prove that the server is offline because ICMP may be disabled by firewall rules. A better test is to check the SSH port itself.

For example:

Bash

nc -vz SERVER_IP 22

For a custom SSH port:

Bash

nc -vz SERVER_IP 2222

Interpreting the result: If the server responds on the network but port 22 does not accept connections, investigate the firewall or SSH service. If the server does not respond to multiple network services, investigate the server's network configuration, upstream filtering, or boot state.

Step 3: Use Console or KVM Access

If SSH is unavailable, you need another way to access the server. For a dedicated server, this may be provided through an out-of-band management method such as:

KVM console
IPMI
Remote console / Web Console
Serial console
Provider recovery console

Once you have console access, log in using a root account or another account with sudo privileges.

Step 4: Check the SSH Service

Once you are inside the server through the console, check the SSH service.

On Ubuntu:

Bash

sudo systemctl status ssh

If the service is inactive or failed, inspect its recent logs:

Bash

sudo journalctl -u ssh -n 50 --no-pager

Then check the configuration:

Bash

sudo sshd -t

If there is a configuration error, sshd -t reports it instead of attempting to start a broken configuration. If the configuration is valid, restart the service:

Bash

sudo systemctl restart ssh

Then verify:

Bash

sudo systemctl status ssh

Step 5: Check Which Port SSH Is Listening On

A common cause of SSH lockout is changing the SSH port without updating the firewall or client configuration.

Check listening TCP sockets:

Bash

sudo ss -lntp | grep ssh

You may see:

Plaintext

LISTEN 0 4096 0.0.0.0:22

This means SSH is listening on port 22. If you configured SSH to use port 2222, connect using the correct port:

Bash

 ssh -p 2222 username@SERVER_IP

Step 6: Check the Firewall

If SSH is running and listening on the expected port, check whether a firewall is blocking access. On Ubuntu, check UFW:

Bash

sudo ufw status verbose

If SSH is not allowed, add the appropriate rule:

Bash

sudo ufw allow 22/tcp

For a custom SSH port:

Bash

sudo ufw allow 2222/tcp

Then verify:

Bash

sudo ufw status numbered

Step 7: Check for Other Firewall Managers

A server may use something other than UFW. Check whether nftables is active:

Bash

sudo nft list ruleset

You can also check iptables:

Bash

sudo iptables -L -n --line-numbers

⚠️

Note: If UFW is managing the firewall, use UFW to make changes rather than manually modifying the underlying rules.

Step 8: Check Whether Your IP Has Been Blocked

Security tools can block an IP address after repeated failed authentication attempts. If Fail2Ban is installed, check its status:

Bash

sudo fail2ban-client status
sudo fail2ban-client status sshd

If your IP is listed as banned, remove only the affected IP:

Bash

sudo fail2ban-client set sshd unbanip YOUR_IP_ADDRESS

(Replace YOUR_IP_ADDRESS with your public IP address).

Step 9: Recover SSH Key Authentication

If the error is Permission denied (publickey), authentication is failing. First confirm that you are using the correct username. Then inspect the user's SSH directory:

Bash

ls -la /home/USERNAME/.ssh
ls -l /home/USERNAME/.ssh/authorized_keys

Correct the directory and file permissions if necessary:

Bash

chmod 700 /home/USERNAME/.ssh
chmod 600 /home/USERNAME/.ssh/authorized_keys
sudo chown -R USERNAME:USERNAME /home/USERNAME/.ssh

(Replace YOUR_IP_ADDRESS with your public IP address).

Step 10: Add a New SSH Public Key

If your original private key is permanently lost, generate a new key pair on your local computer:

Bash

ssh-keygen -t ed25519 -C "your-email@example.com"

Through console access, edit the appropriate user's authorized_keys file on the server:

Bash

nano /home/USERNAME/.ssh/authorized_keys

Add the complete contents of your new .pub file as a new line. Fix permissions and test the new key from your local machine:

Bash

ssh -i ~/.ssh/id_ed25519 USERNAME@SERVER_IP

Step 11: Check SSH Configuration

A syntax error in /etc/ssh/sshd_config can prevent the SSH service from starting. Always validate the configuration before restarting SSH:

Bash

sudo sshd -t

After correcting the configuration:

Bash

sudo systemctl restart ssh

Step 12: Check Disk Space

A completely full filesystem can cause unexpected service failures. Check available space:

Bash

df -h

Find large directories:

Bash

sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h

If logs are consuming excessive space, you can inspect and clear systemd journal logs:

Bash

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M

Step 13: Check Network Configuration

If SSH still cannot be reached, inspect the server's network configuration from the console.

Check network interfaces and routing:

Bash

ip addr
ip route
resolvectl status

Test outbound connectivity:

Bash

ping -c 3 1.1.1.1
ping -c 3 example.com

Step 14: Check Whether the Server Is Actually Booted

If console access shows boot errors, check failed services:

Bash

systemctl --failed

Review the current boot errors:

Bash

 journalctl -b -p err

If a filesystem is failing to mount, investigate /etc/fstab and the affected device before making changes.

Step 13: Check Network Configuration

If SSH still cannot be reached, inspect the server's network configuration from the console.

Check network interfaces and routing:

Bash

ip addr
ip route
resolvectl status

Test outbound connectivity:

Bash

ping -c 3 1.1.1.1
ping -c 3 example.com

Step 15: Test SSH From the Server Itself

If you have console access, test whether SSH is accepting local connections:

Bash

ssh localhost

If localhost SSH works but remote SSH does not, the problem is likely related to firewall rules, external filtering, or source IP blocking.

Step 16: Test the Recovered SSH Connection

After making the required changes, do not immediately close your console session.

From a separate terminal on your local computer, test:.

Bash

ssh USERNAME@SERVER_IP

Confirm that the connection reaches the server, authentication works, and you can obtain a shell. Only then should you close the recovery console.

Common SSH Recovery Scenarios

UFW Was Enabled Before SSH Was Allowed: Use KVM access, run sudo ufw allow OpenSSH.
SSH Configuration Was Edited Incorrectly: Use console access, run sudo sshd -t, fix the reported error, and restart SSH.
The SSH Key Was Deleted: Add a new public key to ~/.ssh/authorized_keys and fix permissions (chmod 600).
Your IP Was Banned: Run sudo fail2ban-client set sshd unbanip YOUR_IP_ADDRESS.
Out of Disk Space: Run df -h and delete large unnecessary log files.

What You Should Not Do During SSH Recovery

Do not reinstall the operating system immediately:Reinstallation can destroy data and configuration.
Do not permanently enable password authentication: Disable it again after recovery.
Do not delete all firewall rules: A full firewall reset (iptables -F) may expose other services.
Do not randomly modify network configuration.
Do not close your only working console session before testing SSH.

What You Should Not Do During SSH Recovery

Do not reinstall the operating system immediately:Reinstallation can destroy data and configuration.
Do not permanently enable password authentication: Disable it again after recovery.
Do not delete all firewall rules: A full firewall reset (iptables -F) may expose other services.
Do not randomly modify network configuration.
Do not close your only working console session before testing SSH.

How to Prevent Future SSH Lockouts

Keep More Than One Authorized Key: Maintain a secondary SSH key stored securely.
Test Firewall Changes Before Disconnecting: Verify that SSH remains allowed before ending the current session.
Validate SSH Configuration Before Restarting: Always run sudo sshd -t before restarting SSH.
Maintain Tested Backups: Backups are important for filesystem corruption and accidental configuration changes.

Conclusion

Losing SSH access does not always mean that your Linux dedicated server needs to be reinstalled. By identifying the failure, checking the SSH service and configuration, reviewing firewall and authentication settings, and using KVM or other console access when necessary, you can usually restore access without affecting your existing workloads.

Need a dedicated server with reliable recovery options?

Whether you are running websites, databases, applications, or production workloads, check out Servers99 for high-performance dedicated servers with reliable infrastructure and the resources needed to keep your workloads running.