When SSH stops working, the server is usually still running; only port 22 is blocked. Every D4 Networks VPS has a browser console that connects directly, so you can log in and fix SSH without a working SSH connection.
1. Open the console
In the client area, go to Services, open the affected service, and click Console under Service management. You get a login prompt from the server itself. Log in as root with your root password.
If you do not know the root password anymore, use Change password under Service actions first. Then log in on the console with the new password.
2. Confirm sshd is running
$ systemctl status ssh$ systemctl status sshdIf the service is dead, a broken config file is the most common reason. Check the config before you restart:
$ sshd -t $ systemctl restart sshd
sshd -t prints the exact broken line in /etc/ssh/sshd_config. Fix it, run sshd -t again until it prints nothing, then restart. On Ubuntu and Debian the service name is ssh.
3. Check the firewall
The most common cause of a lockout: a firewall was enabled without an SSH rule, or the rule allows the wrong port.
$ sudo ufw status verbose $ sudo ufw allow OpenSSH
$ sudo firewall-cmd --list-all $ sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload
If sshd listens on a custom port (ss -tlnp | grep sshd shows which one), allow that port number instead.
4. Check fail2ban
If SSH works from your phone's hotspot but not from home, fail2ban has banned your own IP after failed login attempts:
$ sudo fail2ban-client status sshd $ sudo fail2ban-client set sshd unbanip YOUR.IP.HERE
The status output lists the banned IPs. Your public IP is what curl ifconfig.me shows on the machine you connect from. You can add your home IP to ignoreip in /etc/fail2ban/jail.local so this cannot happen again.
5. Check key permissions
If password login is disabled and your key is rejected, the reason may be file permissions. OpenSSH refuses keys with open permissions and does not say why:
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys $ tail -f /var/log/auth.log
Watch the log while you try to connect from your machine; it shows the exact reason for the refusal. On RHEL-based distros the log is /var/log/secure (or use journalctl -u sshd -f).
6. Test before you close the console
From your own machine, open a new SSH session and check that it works. Keep the console tab open until it does. If you edited sshd_config, test a second new connection too, because the first one may reuse an old channel.
When the VM will not even boot
If the console shows kernel errors or an emergency shell, the problem is not SSH. Use Toggle Rescue Mode under Service actions to boot a temporary recovery system, mount your disk, and repair it from there. If you are not sure what to do, open a ticket before you change anything.
Quick reference
| Symptom | Likely cause | Fix from console |
|---|---|---|
| Connection refused | sshd not running or bad config | sshd -t, fix, restart |
| Connection timed out | Firewall blocking 22 | Allow SSH in ufw or firewalld |
| Works from other networks only | fail2ban banned your IP | fail2ban-client set sshd unbanip |
| Permission denied (publickey) | Key or directory permissions | chmod 700 ~/.ssh, 600 authorized_keys |
Where to go next
To prevent the next lockout: always add your SSH rule before you enable a firewall (see our firewall setup guide), add your own IP to the fail2ban ignore list, and keep a second sudo user with its own key as a backup way in.