Linux VPS not responding to SSH: how to recover access without reinstalling
Linux VPS frozen and SSH won't connect? Diagnose the real cause (network, firewall, sshd, full disk) and recover access without reinstalling from scratch.
A Linux VPS that stops responding to SSH is the kind of problem that looks bad but rarely is. In 90% of cases the machine is running normally — what failed was a specific component between you and the shell: network route, firewall, the sshd daemon, or the disk filled up and the system stopped accepting new connections.
This guide is for anyone with an inaccessible Linux VPS right now who needs to recover access without hitting the reinstall button. Reinstalling wipes everything and is almost always unnecessary. The right path is to diagnose through the hosting panel’s out-of-band console, identify the real cause, and fix it in a few minutes.
Estimated time: 10 to 20 minutes, depending on the cause. Assuming Ubuntu 22.04 or 24.04 LTS — the commands work with minor variations for Debian 12, AlmaLinux 9, and Rocky Linux 9.
Prerequisites
You need the Hostini panel open with access to the out-of-band console (VNC or serial) for the affected VPS, the current root password or a user with sudo, and a second terminal/tab to test reconnection without losing the console session.
Ubuntu 22.04 / 24.04 LTS 22/tcp Hostini panel 10–20 min Quick triage: find out what failed
Before opening the console, two tests from outside are worth running to rule out hypotheses. They take 30 seconds and save you from investigating the wrong thing.
From your local computer, test whether the VPS responds to ping:
ping -c 4 YOUR.VPS.IPIf ping comes back, the machine is alive and the network is working. If it doesn’t come back, it could be a datacenter network issue (rare), the VPS is powered off, or ICMP is being blocked by a firewall — move on to the next test.
Test port 22 specifically with nc or telnet:
nc -vz YOUR.VPS.IP 22A succeeded result means sshd is listening and the firewall allows it — the problem is authentication or a fail2ban ban. A Connection refused result means sshd is not running. Connection timed out means the firewall is blocking or the VPS has no network.
These two outputs already split the problem into three clear categories: network/VPS down, daemon down, or authentication. You open the console with a hypothesis, not blind.
Accessing the out-of-band console
The console is an emergency channel that connects directly to the virtual machine’s serial terminal — independent of SSH, firewall, or network. It’s your spare key.
In the Hostini panel, go to Services → your VPS → Console. The console opens in a window in the browser itself. In some browsers the keyboard focus needs to be activated by clicking once on the black area.
Log in with root and the password set during provisioning, or with your sudo user. If you’ve forgotten the root password, use the panel’s reset procedure — it reboots the VPS in single-user mode and lets you reset it.
Console latency is higher and there’s no command history by default. Avoid typing long commands manually — copy and paste when possible. Destructive commands with wrong syntax will still execute.
Diagnosis in the console: 4 checks in order
Once inside the console, run these four checks in sequence. The first one that fails is probably your root cause.
1. Is the sshd daemon running?
sudo systemctl status sshIf it shows active (running), ok — move on to the next. If it shows inactive, failed, or dead, the service is down. Bring it up with:
sudo systemctl start ssh
sudo systemctl enable sshLook at the log of the most recent messages to understand why it went down:
sudo journalctl -u ssh -n 50 --no-pagerCommon causes of failed: invalid syntax in /etc/ssh/sshd_config after manual editing, corrupted host certificate, or OOM killer killing the process.
2. Is sshd listening on the expected port?
sudo ss -tlnp | grep sshExpected output with port 22:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))If the port is different from 22, you or someone edited Port in /etc/ssh/sshd_config. Set it back to 22 (or open the new port in the firewall — next item) and restart the service.
3. Is the firewall letting it through?
On Ubuntu/Debian the default firewall is ufw:
sudo ufw status verboseLook for a line 22/tcp ALLOW IN Anywhere. If it’s not there, add it:
sudo ufw allow 22/tcp
sudo ufw reloadOn AlmaLinux/Rocky use firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadIf you enable ufw without first allowing port 22, the SSH connection drops instantly. The out-of-band console fixes it, but the headache is avoidable: always sudo ufw allow 22/tcp before sudo ufw enable.
4. Is the disk full?
df -hIf / or /var shows 100% (or 99% with Avail at zero), sshd can’t create session files and new connections fail silently after the handshake. Free up space:
sudo journalctl --vacuum-time=2d
sudo apt clean
sudo find /var/log -name "*.gz" -mtime +7 -deleteThen run df -h again to confirm you’ve freed at least 500 MB and try SSH once more.
Less obvious causes
When the four checks above pass but SSH still won’t connect, it’s worth checking three secondary culprits.
fail2ban banned your IP
If you mistyped your password several times or have another service running on the IP that triggered the ban, your IP may be on the blacklist:
sudo fail2ban-client status sshdThe output lists banned IPs. To unban yours:
sudo fail2ban-client set sshd unbanip YOUR.PUBLIC.IPTo find your public IP from outside the VPS, run curl ifconfig.me in a local shell — ISPs with CGNAT hand out IPs different from what you’d expect.
Broken sshd_config
Manual edits to /etc/ssh/sshd_config break the daemon silently when they contain invalid syntax. Validate:
sudo sshd -tNo output = config ok. Any message points to the problematic line. Fix it and restart:
sudo systemctl restart sshSSH host key change
If you reinstalled SSH packages or restored a snapshot, the host key may have changed. From your local computer, the client complains with REMOTE HOST IDENTIFICATION HAS CHANGED. Remove the old entry:
ssh-keygen -R YOUR.VPS.IPAnd reconnect normally.
Verification: confirm it’s back
Before closing the console, validate recovery through two independent paths.
In a local tab, open a new SSH session normally:
ssh [email protected]If it connects, great. Keep the session open while you do the next step.
Still with the out-of-band console open, confirm that the SSH session is registered:
sudo ss -tnp | grep :22You should see at least one ESTAB (established) connection coming from your IP. This proves that network, firewall, and sshd are working end-to-end.
Whenever you’re about to edit sshd_config, ufw, or iptables, leave the console open in one window and open a second SSH session to test the change. If the second session works, you can close the first one safely. This two-session habit prevents 90% of lockouts.
Next steps
Recovering access is just the beginning — afterward it’s worth hardening the configuration to prevent recurrence.
- Configure SSH key authentication and disable passwords with
PasswordAuthentication noinsshd_config. Before closing the session, test the key in a second tab. - Install and tune
fail2banto ban IPs with a reasonable bantime (1h) and maxretry of 5 — banning too aggressively creates lockouts of your own. - Take regular snapshots of the VPS from the panel before major changes to SSH or the firewall. Rolling back a snapshot is faster than reinstalling.
- If you manage multiple VPSes, consider centralizing access with a bastion host — a single port exposed to the internet, with the rest behind it.
- Document your SSH port, admin user, and console procedure in your own runbook. In an emergency, nobody wants to remember this from memory.
If you need a VPS with reliable out-of-band console and integrated snapshots — which makes this kind of recovery trivial — the Hostini VPS delivers both in the standard panel, at no additional cost.
Frequently asked questions
Why does my Linux VPS respond to ping but not to SSH?
Ping responds at layer 3 (ICMP) and SSH is layer 7 (TCP/22). If ICMP comes back but TCP/22 doesn't, the VPS kernel is alive but sshd has stopped, is listening on another port, or the firewall (ufw/iptables/nftables) is blocking port 22. Use the out-of-band console from the panel to inspect `ss -tlnp` and `ufw status`.
Does rebooting the VPS from the panel fix a stuck SSH?
It fixes things when the cause is a zombie process, kernel oops, or recent OOM killer activity — basically any inconsistent memory state. It doesn't fix things if the cause is persistent configuration: broken sshd_config, a bad firewall rule, or a full root disk. That's why it pays to diagnose via console before rebooting blindly.
How do I access the VPS without SSH working?
Through the serial/VNC out-of-band console offered in the hosting panel. This channel is independent of sshd and the firewall — it connects directly to the virtual machine's tty. You log in with the root password or sudo user that already existed, and you can edit files, restart services, and adjust network rules.
Can a full disk bring down SSH?
Yes. When `/` or `/var` hits 100%, sshd can't write to `/var/log/auth.log`, can't write to `/run`, and can't create temporary session files — and the connection fails right after the handshake. Cleaning old logs from `/var/log` and packages from `/var/cache/apt` usually restores access in seconds.
I changed the SSH port and locked myself out. How do I revert?
Get in through the out-of-band console as root, open `/etc/ssh/sshd_config`, change `Port` back to 22 (or to a port the firewall allows), run `sudo systemctl restart sshd`, and adjust `sudo ufw allow 22/tcp`. Always test the new port in a second session before closing the current one — that's the number one mistake when hardening SSH.
Could fail2ban be blocking my IP?
Yes, if you mistyped your password several times. Via console, run `sudo fail2ban-client status sshd` to see banned IPs. To unban yours, use `sudo fail2ban-client set sshd unbanip YOUR.IP.HERE`. Confirm your public IP with `curl ifconfig.me` first — ISPs with CGNAT may give you a different IP than you expected.