VPS
Cannot connect / SSH connection refused
Diagnose and fix the common reasons an SSH connection to your Victus VPS is refused, times out, or rejects your password/key.
SSH failures usually fall into a few clear buckets, and the exact error message tells you which one. Work through this from the top — most problems are fixed without touching the VPS itself.
Read the error message
| Symptom | Most likely cause |
|---|---|
| Connection timed out | VPS is off/booting, wrong IP, or a firewall is dropping traffic |
| Connection refused | sshd is not running or is listening on a different port |
| Permission denied (publickey) | Wrong key, or password auth is disabled |
| Permission denied (password) | Wrong root password |
| Host key verification failed | The VPS was rebuilt — clear the old fingerprint |
Quick checks first
- Confirm the VPS shows as "running" in the control panel; if not, start it and wait 1-2 minutes.
- Double-check the IP address in the Network view — copy/paste it rather than typing.
- Verify your own internet connection and try again; check https://status.victuscloud.com for platform incidents.
- Test basic reachability from your machine (see the ping/port test below).
# Is the host reachable at all?
ping YOUR_VPS_IP
# Is the SSH port open? (Linux/macOS)
nc -vz YOUR_VPS_IP 22
# Verbose SSH to see exactly where it fails
ssh -vvv root@YOUR_VPS_IPThe #1 self-inflicted cause: ufw
If you enabled ufw without first running "ufw allow OpenSSH", you locked yourself out. This does NOT return "refused" — it usually times out. Fix it from rescue mode or the panel console, then allow OpenSSH.
Host key changed after a rebuild
# Remove the stale fingerprint, then reconnect
ssh-keygen -R YOUR_VPS_IP
ssh root@YOUR_VPS_IPWhen SSH is truly dead, use the panel console
Victus VPS includes a browser console (serial + noVNC) in the panel. Use it to log in directly, inspect sshd with "systemctl status ssh", check "ufw status", or fix the config even when the network path is blocked.
# From the panel console, once logged in:
systemctl status ssh # is the daemon running?
systemctl restart ssh # restart it
ss -tlnp | grep :22 # confirm it is listening on 22
ufw status # is a rule blocking you?Was this article helpful?