no route to host on new droplet

October 15, 2014 6.4k views
rc870240
By:
rc870240

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 DO.com. 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?

5 comments
  • sierracircle October 15, 2014

    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?

  • asb MOD October 15, 2014

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

  • rc870240 October 15, 2014

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

  • rc870240 October 15, 2014

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

  • rc870240 October 15, 2014

    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’]

Log In to Comment
4 Answers
rc870240 October 15, 2014
[deleted]
Reply
sierracircle October 15, 2014

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

+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:
http://www.yougetsignal.com/tools/open-ports/

Reply
  • rc870240 October 15, 2014

    +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!

snowyurik December 16, 2014
[deleted]
Reply
amel August 10, 2016

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
  sources: 
  services: dhcpv6-client http https imap imaps smtp smtps ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  sourceports: 
  icmp-blocks: 
  rich rules:

Manually adding the specific port resolves this issue for now:

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