Question

no route to host on new droplet

Posted October 15, 2014 7k 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 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?

Add a comment
rc870240
By:
rc870240
Add a comment
5 comments
  • sierracircle October 15, 2014
    Reply Report

    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 October 15, 2014
    Reply Report

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

  • rc870240 October 15, 2014
    Reply Report

    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
    Reply Report

    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
    Reply Report

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

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers
rc870240 October 15, 2014
[deleted]
Reply Report
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 Report
  • 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!

    Reply Report
snowyurik December 16, 2014
[deleted]
Reply Report
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 Report
Submit an Answer

Looking for something else?

Ask a new question Search for more help