When SSH stops answering, the VNC console is your only way into the server. It shows the VPS screen as if you were sitting in front of the machine, and it keeps working even when the network is misconfigured or the firewall blocks every incoming connection.
When the console becomes essential
- A firewall rule applied too early closes port 22 and cuts off remote access.
- An IP address, gateway or DNS server changed in the network configuration pushes the server off the network.
- The disk is full: services no longer start, but the system is still reachable through the console.
- The server does not boot properly after a kernel update.
In all these cases, no SSH client will help. The console is out-of-band access: it does not depend on the guest system's network configuration.
Where to find the console
Log in to your client area, open the details of the VPS service concerned, then launch the console. It opens directly in the browser, with no software to install. At the login prompt, use the system credentials: root with the initial password if you have not changed it, or your usual administrator account.
Regaining control: the classic cases
A firewall that is too strict
ufw status ufw allow 22
If you cannot connect at all, temporarily disable the firewall from the console, then restore the rules one by one, testing SSH access after each change.
A wrong network configuration
ip a ip route
On Ubuntu, Netplan files live in /etc/netplan/. Fix the address, the gateway or the DNS servers, then apply the configuration with netplan apply. Keep the console open until SSH answers again.
A full disk
df -h journalctl --vacuum-size=200M
System logs are usually the first thing to clean up. Then check local backups and your applications' temporary files.
A service that will not start
systemctl status ssh systemctl restart ssh
If the screen stays black
A black screen can indicate a hung kernel or an interrupted boot. Request a reboot from the service details page, then watch the boot messages in the console. If the server does not come back online, open a ticket stating the time of the last change, the commands you ran and the symptoms you observed: this saves considerable diagnostic time.
Avoiding the need for it
- Test any firewall or network change before closing your SSH session.
- Keep a second session open during critical changes.
- Monitor disk space before it fills up.
- Keep a recent backup: the console lets you repair a server, not restore lost data.
