Fix 'Connection refused' on a new GPU instance

The moment I distrust most on a fresh deployment is the instant the dashboard says Running, because on some providers that status does not mean SSH is actually listening yet.

ssh: connect to host YOUR_VM_IP port 22: Connection refused
ssh: connect to host YOUR_VM_IP port 22: Connection timed out

Refused is not the same as timed out

The two errors point in different directions. Connection refused means a machine answered at that address and actively rejected the connection, usually because sshd is not listening yet, which is common in the first moments after a provider marks a VM Running. Connection timed out or no route to host means nothing answered at all, which usually points at the wrong IP, an instance that is no longer running, or a firewall rule dropping the packets outright rather than rejecting them. A quick way to tell them apart without an authentication attempt is nc -zv YOUR_VM_IP 22, which reports open, refused or a timeout on the port alone.

Running does not always mean SSH is ready

Nothing in DeployGPU checks that SSH answers before a deployment is marked Running. QuantaCloud only reports Running after its own startup script has finished, which tends to leave SSH ready by the time the status changes. Other providers, Hyperstack in particular, mark a VM ready as soon as it is ACTIVE with a public IP, with no check that SSH is listening, so the first attempt can be refused for a short time after the dashboard already says Running.

The fix is not to keep clicking connect by hand. Retry in a loop and let it succeed on its own:

until ssh -o ConnectTimeout=5 -o BatchMode=yes -o StrictHostKeyChecking=accept-new ubuntu@YOUR_VM_IP true 2>/dev/null; do
  sleep 5
done

Swap in the username for your provider. Once that loop exits, sshd is answering and a normal ssh command connects.

The Vast.ai proxy port

Vast.ai is the one exception to port 22. It puts SSH behind a proxy on a port the dashboard shows next to the deployment, not 22, and connecting on 22 instead produces exactly this error. Copy the full command, port included, rather than assuming the usual port.

The instance is gone

An instance that was stopped, or one a provider lost, disappears from the deployments list rather than sitting there showing an error. If the IP being retried no longer belongs to anything in the dashboard, that is the actual cause, not a slow boot. DeployGPU checks every running instance every 5 minutes, and if a provider confirms a machine is gone, the deployment is stopped and the unused time refunded automatically, with no email sent for that specific event. Check the deployments list before retrying an IP for more than a few minutes.

A firewall rule set on the instance itself

If SSH worked earlier in the same session and then stopped, look at what changed on the instance before blaming the provider. A ufw rule enabled without an explicit allow for SSH first locks out the same connection needed to fix it:

sudo ufw allow OpenSSH

Run that, and any other allow rules the instance needs, before sudo ufw enable, not after. If a restrictive rule is already active and the instance is already locked, there is no console access documented here to undo it remotely. The practical fix is to stop the instance and launch a new one, allowing SSH before enabling anything this time. Stopping deletes the disk, which is one more reason to keep anything irreplaceable off the instance as work happens, not only at the end.

When to contact support

Contact support if the deployments list still shows the instance as Running, the IP has not changed, and a retry loop has kept failing well past the usual first-minute window. The contact page is the way in. The SSH guide covers the rest of connecting, including keys and ~/.ssh/config.