-1

So i have making a control panel of sorts with php on my webserver that is able to send commands to my dedicated server (remote server) via ssh2.

This works fine, however i have noticed that after a few times of it reconnecting to ssh2 it stops working and just times out on the connection. (It also does not work trying to ssh directly from the server to the target)

I have flushed iptables but that seems to have no effect.

I checked auth.log and the system log but neither seem to show up anything about the failed connection.

The target server is running Ubuntu 16.04 and is an OVH server.

Could someone please offer suggestions on things i could try/check to resolve this issue? I thought since it's an OVH server it might be getting picked up by their Anti-DDoS but as far as i am aware, there is no way for me to check that.

Traceroute to port 22 from the webserver - Unsuccessful

# traceroute -n -T -p 22 TARGET
traceroute to TARGET (TARGET), 30 hops max, 60 byte packets
 1  * * *
 2  185.145.200.13  0.293 ms  0.277 ms  0.316 ms
 3  185.145.200.11  0.195 ms  0.188 ms  0.208 ms
 4  * * *
 5  91.121.128.92  9.393 ms * *
 6  * * *

until 30 * * *

Traceroute to port 22 from the webserver - Successful

traceroute -n -T -p 22 TARGET
traceroute to TARGET (TARGET), 30 hops max, 60 byte packets
 1  * * *
 2  185.145.200.13  0.335 ms  0.352 ms  0.297 ms
 3  185.145.200.11  0.273 ms  0.267 ms *
 4  * * *
until
30  * * *
bgtvfr
  • 1,262
  • 10
  • 20
Mattigins
  • 13
  • 6
  • 2
    A bunch of information is missing here. A packet capture from each end of the connection while trying to open a connection as well as a traceroute showing what it looks like before the connection stops working. – kasperd Apr 15 '17 at 12:17
  • Not sure how to do the packet capture but i will add the successful traceroute to the main post. – Mattigins Apr 15 '17 at 12:47
  • The supposedly successful traceroute fails even earlier. – kasperd Apr 15 '17 at 13:12
  • That's what i thought but i thought i must have been reading it wrong. I can confirm that the ssh connection worked after that traceroute though.. – Mattigins Apr 15 '17 at 13:25
  • Nothing is shown in the tcpdump for an unsuccessful attempt – Mattigins Apr 15 '17 at 13:30
  • 1
    Your `traceroute` and `ssh` commands are probably connecting to two different IP addresses. – kasperd Apr 15 '17 at 13:37
  • how could that be since i am using the same ip address for both commands? – Mattigins Apr 15 '17 at 13:43
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/57152/discussion-between-kasperd-and-mattigins). – kasperd Apr 15 '17 at 14:07

2 Answers2

1

I'm also just shooting blindly here:

Maybe ovh has enabled some kind of "network protection" to prevent servers being compromised by brute force attacks.

To figure out, try to run run sshd on a different port eg 6022 and see if the problem persists. 


ListenAddress
Specifies the local addresses sshd should listen on. The following forms are allowed:
ListenAddress host|IPv4_addr|IPv6_addr
ListenAddress host|IPv4_addr:port
ListenAddress [host|IPv6_addr]:port
Source : https://www.ssh.com/ssh/sshd_config/
bgtvfr
  • 1,262
  • 10
  • 20
  • 1
    If I remember correctly, I had problems with my ovh server when I used port 22, and they disappeared when I've started using alternative port. Hope this helps. – bgtvfr Apr 21 '17 at 09:19
  • I actually figured it out myself. But since you had the correct answer i selected yours :) The problem was actually on the web server side, it was throttling port 22 outgoing for some reason. – Mattigins Apr 21 '17 at 16:35
0

I'm just shooting blindly here:

  • Could it be something related to routing? Maybe you have both IPv4 and IPv6 enabled for the hostname you are trying to reach, or just multiple IPv4 routes? Perhaps one of the routes is broken.

  • Could there be some kind of firewall that limits your requests in front of your ssh server?

  • Do you have fail2ban or similar installed? Maybe it is adding something to your iptable chains again just after you flush them?

Could also be firewalls or traffic limiters along the route of your request. To debug; try setting up a static network route directly from A to B and work your way one step at a time out through your network, until you find the broken link.

Johan Thomsen
  • 33
  • 4
  • I am not familiar with routing etc but i can confirm that fail2ban is not installed on the target. Is there a way to confirm if there is a firewall infront of my ssh? – Mattigins Apr 13 '17 at 09:18
  • - Query DNS of your hostname for all A and AAAA records to see what possible target IP's you have for your hostname. - Check your ifconfig to see whether your server holds the public IP that you are accessing. If not, you know at least that there is NAT'ing involved, which should point you in the direction of the NAT'ing router. - If there are multiple IP's for your server, IP4 or 6 or both, use tracepath or traceroute to get an idea of the net route from A to B. - # route -n will reveal any stupid static routes setup for your box. – Johan Thomsen Apr 13 '17 at 09:35
  • Last time I had an issue like yours it was due to my host name resolving to two different IP's (round-robin). And since my failover IP was on an internal network, it was not accessible outside of office, thus causing ssh to timeout sporadically depending on which IP the client was trying, but only when I tried connecting from home. – Johan Thomsen Apr 13 '17 at 09:40
  • So i just tried to the ip directly and still the same issue.. – Mattigins Apr 13 '17 at 09:47
  • I can also confirm that i can access mysql from the web server to the target server. So it's just blocking the web servers access to ssh – Mattigins Apr 13 '17 at 09:48
  • 1
    Does it only happen when ssh through php ? Or can you reproduce if you ssh manually from the shell a couple of times? If so, please have a look at the ssh client verbose output $ ssh -vvv HOST ... You should be able to see at which step in the connect process it hangs then. – Johan Thomsen Apr 13 '17 at 10:24
  • Yes, it does happen in shell aswell.. The verbose output was not helpful `debug1: Connecting to * port 22.` `debug1: connect to address * port 22: Connection timed out` – Mattigins Apr 13 '17 at 10:34
  • Traceroute added to original post. – Mattigins Apr 14 '17 at 13:08