no route to host on new droplet

October 15, 2014 6.4k views

I’m new to DO and have been struggling for the last few days to get a working droplet up and running. What typically happens is that the droplet is ‘successfully’ created and I can access it from the console on However, if I try to ssh to it from outside of DO I get 'no route to host’; but, oddly enough, I can ping the droplet from the same system that the ssh failed on. I have an open ticket on this and periodically get a 'it should be working’ response (it usually isn’t). I want to think that this isn’t typical for DO hosting - any suggestions?

  • are you using the IP address, or a domain you are pointing to that droplet?

    if you are using a domain, sometimes it can take a day or two for the domain to start resolving properly across the web. In the meantime you can just use the IP they give you for that droplet.

    If you are using the IP, that is unusual, unless you set it up with an alternative ssh port, or added a firewall and have all ports closed.

    Can you give a little more information, like what image you used, OS, did you add ssh keys? any other clues you might think of?

  • Is it possible that your local network or ISP filter port 22? Have you tried setting a custom SSH port?

  • I can ssh from the same laptop to AWS with no problem so I don’t think it is a filtering issue.

  • I might try creating a droplet in a different region and see if that makes a difference. Currently working in nyc

  • I am attempting to use the IP to connect. I have tried two droplets one with ssh and one without (same behavior). I selected the ubuntu install in both cases. no alternate ssh port, no firewall, i would say it is a pretty generic install (which is where I like to start). [moved this from being an ‘answer’]

4 Answers


+1 for this. You will want to do that anyway.

to change port:

sudo nano /etc/ssh/sshd_config

You will see the place where it says the port 22…change that to whatever, then ctrl X and then:

sudo service ssh reload

Then, just to be sure, run (if your alt port was 2010):

 sudo iptables -A INPUT -p tcp -d 0/0 -s 0/0 --dport 2010 -j ACCEPT

Then check your ports here:

  • +1 indeed.

    I pushed ssh to a high port ‘just for fun’ and it seems to be much better behaved now. I just edited sshd_config and did a restart ssh.

    Thanks all for the helpful advice!

This is weird behavior, as I am experiencing this right now on a Fedora23 droplet. The firewalld tool lists the interfaces and services in the default firewall zone as open. However, the ports are closed. This might have to do with the empty “Sources” field:

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0 eth1
  services: dhcpv6-client http https imap imaps smtp smtps ssh
  masquerade: no
  rich rules: 

Manually adding the specific port resolves this issue for now:

firewall-cmd --add-port=123333 --permanent
Have another answer? Share your knowledge.