Server not responding via SSH: diagnostics and access recovery through VNC console

The situation is familiar to many: the server is running, the site or application responds, but connecting via SSH is impossible. The connection hangs, returns "Connection refused" or "Connection timed out". There is no need to panic — in most cases the cause is trivial and can be resolved in a few minutes. In this article we will go through the most common sources of the problem and show how to restore access through the VNC console without waiting for support and without losing data.

Why SSH stops responding: main causes

The problem almost always falls into one of five categories. The first — the sshd daemon is stopped or exited with an error after a package update or config edit. The second — the SSH port was changed manually or by a script, while the client is still knocking on the standard port 22. The third — a firewall (ufw, iptables, or nftables) blocked incoming connections, for example after applying a new rule set. The fourth — fail2ban added your IP to the ban list after several failed login attempts. The fifth, and most insidious — the disk is filled to 100%: in this case sshd cannot write temporary files and refuses to accept connections, even though the process itself is formally running.

How to get into the server when SSH is unavailable

For such cases, the NodexGo control panel includes a web-based VNC console — the server screen right in your browser. It works bypassing the network and SSH, so it is available even when the server does not respond from the outside. Open the server card, go to "Management", then "VNC access". Enter the login root, then click the "Enter password" button in the console — it will type the root password from the server card, and all you need to do is press Enter. It is better not to type the password manually: characters are not visible during input, and due to keyboard layout issues you can easily get "Login incorrect".

Diagnostics: what to check first

Once logged in through the console, start by checking the SSH service. In Ubuntu and Debian it is called ssh, in CentOS, AlmaLinux, and Rocky it is called sshd. The command will show whether the service is running and whether it has crashed with an error:

systemctl status ssh

If the status is "failed" or "inactive", start the daemon and check the journal for configuration errors.

systemctl start ssh
journalctl -u ssh -n 50 --no-pager

The next step is to verify which port sshd is actually listening on. This is important if someone changed the config without telling you.

ss -tlnp | grep -E 'ssh|:22'

The output will show the real port. If it differs from 22, simply specify the required port when connecting from the client: ssh -p PORT root@IP. If you want to restore the standard port, open the configuration file /etc/ssh/sshd_config, find the Port line and correct the value, then restart sshd. In Ubuntu 24.04 SSH is launched via ssh.socket: after changing the port, run systemctl daemon-reload and systemctl restart ssh.socket.

Checking the firewall and fail2ban

If sshd is running and listening on the correct port, the firewall is most likely to blame. Check the ufw and iptables rules.

ufw status verbose
iptables -L INPUT -n --line-numbers

If ufw is enabled and the SSH rule is missing, add it and make sure the port is open. Replace 22 with the actual port if it is non-standard.

ufw allow 22/tcp
ufw reload

Now check fail2ban. The utility automatically blocks IPs after several failed login attempts — this is a useful protection, but it can also block you yourself, especially if you entered the wrong password several times.

fail2ban-client status sshd

If your IP is present in the banned list, unblock it with the following command, substituting the real address.

fail2ban-client set sshd unbanip YOUR_IP

Disk is full: how to detect and fix

A full disk is one of the least obvious causes of SSH unavailability, because the server continues to operate in this case. Check disk space usage.

df -h

If any partition shows 100% or the Use% value is close to it, you need to free up space. Find large files that can be deleted: most often these are old logs, database dumps, or package manager cache.

du -sh /var/log/* | sort -rh | head -20
apt clean
journalctl --vacuum-size=200M

After freeing up space, restart the SSH service — this is usually sufficient. If the disk runs out regularly, configure log rotation (logrotate), delete old backups and dumps, or choose a plan with a larger disk.

Last resort: reinstalling the OS

If the SSH configuration is so damaged that it cannot be restored, and the data on the server is not critical or has already been saved to a backup, use the "Reinstall OS" button in the server card. The operation takes a few minutes: the disk is wiped, a fresh image of the selected system is installed, the IP address is preserved, and the new root password will appear in the server card. After that you get a clean server with a working SSH and can restore the necessary data and configurations.

How to prevent the problem in the future

A few simple rules will help avoid a recurrence. Before making any changes to the SSH config, open a second SSH session — if something goes wrong, you will have an active connection to roll back. Set up disk space monitoring and alerts when 80% capacity is reached. If you change the SSH port, first add the new rule to the firewall, and only then restart the daemon. Keep up-to-date login credentials for the control panel: the VNC console and the root password in the server card are your safety net in any emergency.

Losing SSH access looks frightening, but in practice it is resolved in 5 to 15 minutes if you know where to look. The VNC console in the NodexGo panel lets you log into the server bypassing the network and eliminate any of the described causes without involving support. Rent a VPS with convenient management and sleep soundly — the tools for quick recovery are always at hand.