Fix 'Connection timed out' when you SSH into a cloud GPU

The SSH connection timed out error means nothing answered at the VM's address before the client gave up, so look at the address, the network in between and whether the VM is up, and not at your key or your username.

ssh: connect to host 203.0.113.10 port 22: Connection timed out
ssh: connect to host 203.0.113.10 port 22: No route to host
ssh: connect to host 203.0.113.10 port 22: Operation timed out

The first two lines are the Linux wording and the third is macOS. OpenSSH ends the line with the system's own error text, as sshconnect.c shows, and Apple's errno.h has the macOS wording (checked 12 November 2026). The address 203.0.113.10 is reserved for documentation by RFC 5737, so use the address on your deployment. A session that connected and then froze or closed is a different problem, and SSH keeps disconnecting covers it. The causes below are in the order I would check them on a rented GPU.

Why an SSH connection timed out is not the same as refused

A refusal is an answer and a timeout is silence. The connect(2) manual says a refused connection "found no one listening on the remote address", so a machine was there and nothing served port 22. The glibc manual describes a timeout as a socket operation that "received no response during the timeout period". Your packets were dropped or never arrived. If your error says Connection refused, read the connection refused page instead.

The wait is part of the symptom. The tcp(7) manual says a new connection retries its first packet 6 times by default, which it puts at up to approximately 127 seconds on Linux. So ssh can sit still for two minutes before it prints anything, and that is the "ssh hangs" people describe. The ssh_config manual says ConnectTimeout is used "instead of using the default system TCP timeout", so a short limit gives you the answer sooner:

ssh -o ConnectTimeout=10 ubuntu@203.0.113.10

What SSH no route to host means

No route to host is the system's text for the error EHOSTUNREACH, which the glibc manual describes as "The remote host for a requested network connection is not reachable." RFC 792 says that in some networks a router that can tell the destination host is unreachable may send a destination unreachable message back to the sender, with code 1 meaning host unreachable. Your machine then has an answer, which is the difference from a timeout. The first suspect is still the address.

Check the address against the deployment

Every launch is a new machine with its own address, and an address from an earlier deployment answers nothing once that machine is gone. Open the Deployments page and compare the address with the one in the ssh command it shows, which you should copy instead of typing. Stop means terminate on DeployGPU, and the disk goes with it. A machine that its provider loses disappears from the list after the 5-minute health check, with no email, and its address stops answering. If the deployment is not listed, a timeout is the expected result and only a new launch fixes it.

A VM that is still starting

A GPU VM usually reaches Running in 1 to 3 minutes, and nothing in DeployGPU checks that SSH answers before it says Running. A machine whose network is not up yet does not answer at all, which looks like this error. The retry loop on the connection refused page uses a 5 second connect timeout, so it works for timeouts too.

If you powered a Verda or Hyperstack VM back on through the API, SSH takes a few more minutes to answer, and on Hyperstack the network can take up to 10 minutes to reach the VM again. The API reference describes the power endpoints.

The wrong port on Vast.ai

Vast.ai is the one provider that does not use port 22. It is dashboard only and labelled Testing Only, and it puts SSH behind a proxy on a port shown on the deployment, so port 22 ends in a refusal or a timeout. Copy the whole command, -p and the port included:

ssh -p PORT root@203.0.113.10

A network that blocks outbound port 22

GitHub's documentation says "Sometimes, firewalls refuse to allow SSH connections entirely." Try the same command from a phone hotspot, and again with any VPN switched off. If it connects there, your network is the cause, so ask its administrator to allow outbound TCP port 22 to the VM, or work from another network. The VM providers listen on port 22 and DeployGPU documents no other SSH port for them, so asking for a different port is not an option.

A firewall on the VM can also produce a timeout. The ufw manual says reject is for letting the sender know that traffic is denied, "rather than simply ignoring it", which is what deny does. The connection refused page covers the lockout from enabling ufw without allowing SSH first.

Test port 22 itself, not ping

Ping is the wrong test. It uses ICMP, which the ping(8) manual calls the "ECHO_REQUEST datagram", while SSH is TCP on port 22 according to RFC 4253, so a firewall can treat them differently. Amazon's EC2 documentation shows the pattern: "To ping your instance, you must add one of the following inbound ICMP rules." A VM can answer SSH while ping gets nothing. Test the TCP port instead, with -w 5 so nc gives up after 5 seconds:

nc -vz -w 5 203.0.113.10 22

Test-NetConnection -ComputerName 203.0.113.10 -Port 22

The nc manual says -z only scans for listening daemons without sending data. A line ending in succeeded! means the TCP connection opened, so the problem is further along, and the permission denied page or the SSH guide is next. In PowerShell, read TcpTestSucceeded in the output. If nc reports failed: Connection refused, use the refused page. If it reports a timeout, keep reading.

Read ssh -vvv and the route

The ssh manual says 3 is the maximum number of -v flags, and -vvv prints every step in order:

ssh -vvv -o ConnectTimeout=10 ubuntu@203.0.113.10

If the output stops after debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22. and ends with debug1: connect to address 203.0.113.10 port 22: Connection timed out, the TCP connection never opened. If it prints debug1: Connection established. and later Connection timed out during banner exchange, the connection opened and the server never sent its identification string, which is a different failure from a blocked path.

To see where the answers stop, run mtr where you have it, or tracert on Windows. In mtr, -T sends TCP SYN packets instead of ICMP echo and -P sets the port. Read the last hop, not every row. The mtr manual warns that some routers give ICMP echo a lower priority, and Microsoft's tracert page says some routers do not reply at all, which shows as a row of asterisks.

mtr -rwn -c 10 -T -P 22 203.0.113.10

tracert 203.0.113.10

When to contact support

Contact support if the deployment is listed, the address matches the dashboard, nc or Test-NetConnection fails from two different networks and a few minutes of retrying changed nothing. Email support@deploygpu.ai with the ssh -vvv output, the nc result, the provider, the deployment ID and the time of the attempts. The contact page is the other way in.