2

I just configured a new server from DigitalOcean. I don't think I changed anything on the server's networking configuration other than changing the ssh port from 22 to 2202, but all of a sudden I am unable to ssh into the server. I was able to intially login a couple times with ssh on port 2202

Please let me know if there is a better StackExchange for this question

$ ssh -p 2202 user@159.89.x.x     
ssh: connect to host 159.89.x.x port 2202: No route to host

I am able to ping the server

$ ping 159.89.x.x    
PING 159.89.x.x (159.89.x.x) 56(84) bytes of data.
64 bytes from 159.89.x.x: icmp_seq=1 ttl=56 time=30.0 ms
64 bytes from 159.89.x.x: icmp_seq=2 ttl=56 time=29.7 ms
64 bytes from 159.89.x.x: icmp_seq=3 ttl=56 time=29.9 ms

--- 159.89.x.x ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 29.756/29.932/30.083/0.134 ms

I turned off all network configurations except my ethernet connections

$ ifconfig 

eth0      Link encap:Ethernet  HWaddr 90:2b:34:d6:e1:d5  
          inet addr:192.168.0.8  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::737e:c4b0:f37c:ab45/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7449 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139088 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6762469 (6.7 MB)  TX bytes:9333612 (9.3 MB)
          Interrupt:18 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1180 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1180 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:109431 (109.4 KB)  TX bytes:109431 (109.4 KB)

Here is the traceroute

$ traceroute 159.89.x.x
traceroute to 159.89.x.x (159.89.x.x), 30 hops max, 60 byte packets
 1  192.168.0.1 (192.168.0.1)  0.455 ms  0.613 ms  0.802 ms
 2  hlrn-dsl-gw09.hlrn.qwest.net (207.225.x.x)  3.641 ms  3.833 ms  4.532 ms
 3  hlrn-agw1.inet.qwest.net (71.217.x.x)  4.763 ms  4.733 ms  4.734 ms
 4  dvr3-brdr-01.inet.qwest.net (208.168.x.x)  4.911 ms  5.347 ms  5.131 ms
 5  den-b1-link.telia.net (213.248.93.94)  5.336 ms  5.327 ms  5.764 ms
 6  sjo-b21-link.telia.net (213.155.133.171)  33.313 ms  29.887 ms  29.980 ms
 7  digitalocean-ic-318773-sjo-b21.c.telia.net (62.115.149.7)  29.570 ms digitalocean-ic-306499-sjo-b21.c.telia.net (62.115.45.22)  30.931 ms  30.938 ms
 8  159.89.x.x (159.89.x.x)  29.617 ms !X  29.838 ms !X  29.614 ms !X

Here is what nmap says (I am pretty unfamiliar with how to effectively use nmap)

$ nmap 159.89.x.x

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-20 09:34 MDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.08 seconds

and 

$ nmap -Pn 159.89.x.x

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-20 09:35 MDT
Nmap scan report for 159.89.x.x
Host is up (0.59s latency).
Not shown: 999 filtered ports
PORT   STATE  SERVICE
22/tcp closed ssh

and 

$ nmap -Pn 159.89.x.x -p 2202  

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-20 12:56 MDT
Nmap scan report for 159.89.x.x
Host is up (0.036s latency).
PORT     STATE    SERVICE
2202/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

From the DigitalOcean console (only way to currently access the machine), I am able to ping 8.8.8.8 as well as curl -vL google.com successfully

Also from the DO console, 

(myserver)$ ip route

default via 159.89.128.1 dev eth0
10.46.0.0/16 dev eth0 proto kernel scope link src 10.46.0.5
159.89.128.0/20 dev eth0 proto kernel scope link src 159.89.x.x

Since I am unable to copy / paste from the DO console, here is an image of sudo iptables -nvL INPUT

output of <code>sudo iptables -nvL INPUT</code>

Brian Leach
  • 327
  • You can try nmap -Pn 159.89.x.x -p 2202 to specifically check the SSH port remotely. Also, access the DO droplet via their Web Console and make sure it has proper connectivity to the internet. Can you ping 8.8.8.8? Can you curl -vL google.com? Also post your route table with ip route. Also, check iptables -nL on the DO droplet too, it might be that it's being blocked at the firewall. – Andrew Mar 20 '18 at 18:39
  • @Andrew I just updated the question with what you asked for, although the output from iptables -nL is long and there is no scroll on the DO console haha. Also, I am unable to copy / paste from that window. What could I grep for? – Brian Leach Mar 20 '18 at 19:04
  • If possibly, the INPUT table is probably the most helpful now, but we need to see the complete rule-set in order to asses the configuration. iptables -nvL INPUT would capture just the INPUT table. – Andrew Mar 20 '18 at 19:09
  • @Andrew added INPUT table config – Brian Leach Mar 20 '18 at 19:29

2 Answers2

3

You forgot to open the port in your firewall. You need to do that, e.g. since you are using firewalld:

firewall-cmd --add-port=2202/tcp

Once it is working, make it permanent.

Michael Hampton
  • 247,473
  • I wish I could buy you a beer. Couple questions. First, since I am using ansible, why didn't this show up in my other servers? They were CentOS 7.0 and this one is CentOS 7.4. Second, how did you know that I am using firewalld? I hadn't heard of this yet – Brian Leach Mar 20 '18 at 19:44
  • Did you change ports on the other servers? Or have a firewall active? Anyway, I saw that it was firewalld from your image. – Michael Hampton Mar 20 '18 at 19:46
  • I did change the ports and did not make any changes to the firewall. I used the same Ansible scripts to commission the server as before. The only difference could be that something changed between CentOS 7.0 and 7.4 – Brian Leach Mar 20 '18 at 23:50
1

It sounds like you might have an iptables conflict blocking port 2202. Try this process as a test to see if you can re-gain access:

iptables-save > ~/iptables.save
iptables -F

Then re-attempt SSH on port 2202. If this works, your firewall rules need adjusting, if it doesn't work, makes sure you don't have a conflict with the Digital Ocean firewall as well.

To restore the rules, run the following:

iptables-restore < ~/iptables.save
Andrew
  • 2,172
  • 3
  • 20
  • 26
  • That worked, you are a champion! Any idea on how it got messed up in the first place? Is that a permanent change? What kind of changes to I need to make to the firewall rules? – Brian Leach Mar 20 '18 at 19:22
  • @BrianLeach Don't do this, as you are using firewalld and this will conflict with your existing firewall. You'll most likely get locked out again, e.g. the next time you reboot. See the other answer with respect to firewalld. – Michael Hampton Mar 20 '18 at 19:34
  • Now that we know it's a firewall issue, you need to properly configure it to allow port 2202/tcp in. @MichaelHampton has the command on how to do that in his answer. – Andrew Mar 20 '18 at 19:36