Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to diagnose why an SSH connection is timing out.

I have two OSX boxes which can SSH to the remote server fine.

I have a two ubuntu boxes, on the same network and subnet which just time-out every time they attempt to SSH into the server.

The two ubuntu boxes can SSH into many other servers just not any domain on this server. It's a cPanel server with multiple sites on the same server.

Output of tcptraceroute

~$ sudo tcptraceroute example.com.au
traceroute to example.com.au (223.130.25.70), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 37.196 ms 37.179 ms 37.160 ms
2 172.18.113.43 (172.18.113.43) 23.195 ms 25.822 ms 24.850 ms
3 * * *
4 172.18.243.105 (172.18.243.105) 31.476 ms * *
5 bundle-ether10.pie10.perth.telstra.net (110.142.134.205) 38.013 ms * *
6 * * *
7 * * *
8 * * tengigabitethernet9-1.wel19.perth.telstra.net (203.50.115.157) 23.386 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * ipll-5016775.gw.aapt.com.au (203.174.177.26) 93.951 ms 94.883 ms
18 * * *
19 * * *
20 * * *
21 ve101.rn-400harris-cer-01.pipenetworks.com (121.101.138.213) 84.761 ms 86.856 ms 
91.565 ms
22 ip-134-153-161-203.static.pipenetworks.com (203.161.153.134) 105.421 ms 106.249 ms 
106.258 ms
23 ge-0-1-40-1-mel.as45638.net.au (112.140.177.254) 92.756 ms 94.176 ms 95.147 ms
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

ping only seems to be slow between the router when heading out to the problem server. If I ping the router directly it's fine. Eg

~$ ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_req=1 ttl=64 time=0.610 ms
64 bytes from 192.168.1.254: icmp_req=2 ttl=64 time=0.275 ms
64 bytes from 192.168.1.254: icmp_req=3 ttl=64 time=0.298 ms
64 bytes from 192.168.1.254: icmp_req=4 ttl=64 time=0.266 ms

Firewall isn't blocking anything.

~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Added tcpdump output as requested.

~$ sudo tcpdump -vv -n host 223.130.25.70
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:16:47.638574 IP (tos 0x0, ttl 64, id 11947, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.48268 > 223.130.25.70.2683: Flags [S], cksum 0xbb03 (incorrect -> 0x39bc), seq 3990493292, win 14600, options [mss 1460,sackOK,TS val 374421191 ecr 0,nop,wscale 7], length 0
18:16:48.637914 IP (tos 0x0, ttl 64, id 11948, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.48268 > 223.130.25.70.2683: Flags [S], cksum 0xbb03 (incorrect -> 0x38c2), seq 3990493292, win 14600, options [mss 1460,sackOK,TS val 374421441 ecr 0,nop,wscale 7], length 0
18:16:50.641915 IP (tos 0x0, ttl 64, id 11949, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.48268 > 223.130.25.70.2683: Flags [S], cksum 0xbb03 (incorrect -> 0x36cd), seq 3990493292, win 14600, options [mss 1460,sackOK,TS val 374421942 ecr 0,nop,wscale 7], length 0
18:16:54.649912 IP (tos 0x0, ttl 64, id 11950, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.48268 > 223.130.25.70.2683: Flags [S], cksum 0xbb03 (incorrect -> 0x32e3), seq 3990493292, win 14600, options [mss 1460,sackOK,TS val 374422944 ecr 0,nop,wscale 7], length 0
18:17:02.665920 IP (tos 0x0, ttl 64, id 11951, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.48268 > 223.130.25.70.2683: Flags [S], cksum 0xbb03 (incorrect -> 0x2b0f), seq 3990493292, win 14600, options [mss 1460,sackOK,TS val 374424948 ecr 0,nop,wscale 7], length 0
18:17:18.713918 IP (tos 0x0, ttl 64, id 11952, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.48268 > 223.130.25.70.2683: Flags [S], cksum 0xbb03 (incorrect -> 0x1b63), seq 3990493292, win 14600, options [mss 1460,sackOK,TS val 374428960 ecr 0,nop,wscale 7], length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

It seems the checksum errors above are due to checksum offloading so I'm posting the output again here without the errors.

$# tcpdump -vv -K -n dst host 223.130.25.70
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:02:48.348594 IP (tos 0x0, ttl 64, id 46577, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.59820 > 223.130.25.70.2683: Flags [S], seq 2943223161, win 14600, options [mss 1460,sackOK,TS val 351711368 ecr 0,nop,wscale 7], length 0
17:02:49.345912 IP (tos 0x0, ttl 64, id 46578, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.59820 > 223.130.25.70.2683: Flags [S], seq 2943223161, win 14600, options [mss 1460,sackOK,TS val 351711618 ecr 0,nop,wscale 7], length 0
17:02:51.349914 IP (tos 0x0, ttl 64, id 46579, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.59820 > 223.130.25.70.2683: Flags [S], seq 2943223161, win 14600, options [mss 1460,sackOK,TS val 351712119 ecr 0,nop,wscale 7], length 0
17:02:55.353915 IP (tos 0x0, ttl 64, id 46580, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.59820 > 223.130.25.70.2683: Flags [S], seq 2943223161, win 14600, options [mss 1460,sackOK,TS val 351713120 ecr 0,nop,wscale 7], length 0
17:03:03.369916 IP (tos 0x0, ttl 64, id 46581, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.59820 > 223.130.25.70.2683: Flags [S], seq 2943223161, win 14600, options [mss 1460,sackOK,TS val 351715124 ecr 0,nop,wscale 7], length 0
17:03:19.417916 IP (tos 0x0, ttl 64, id 46582, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.100.59820 > 223.130.25.70.2683: Flags [S], seq 2943223161, win 14600, options [mss 1460,sackOK,TS val 351719136 ecr 0,nop,wscale 7], length 0

Any suggestions how to try track this down?

share|improve this question
    
Are there any firewall rules in place that only allows the two Macs to ssh? –  Danie Jan 28 '13 at 8:21
    
No, the firewall on the remote server should not be blocking anything like that. –  Ben Jan 28 '13 at 8:26
    
have you tried to tcpdump and see if you get 'ack' packets back from the remote server? –  Danie Jan 28 '13 at 8:28
    
Nope, hadn't tried that. I've added the output. It seems there is a checksum error but I'm unsure what that means. Gives me something else to Google though. –  Ben Jan 28 '13 at 8:45
    
And if you run tcpdump with the following, tcpdump -vv -n host 223.130.25.70 Basically want to see if there is two-way comms –  Danie Jan 28 '13 at 11:41

2 Answers 2

Try disabling some of authentication methods like :

echo "GSSAPIAuthentication no" > /home/`whoami`/.ssh/config
share|improve this answer
    
I tried disabling a few but it didn't make any difference. –  Ben Jan 29 '13 at 10:46

Try this first: (On Client)

open /etc/ssh/ssh_config and add following line:

ServerAliveInterval 60

This will send every 60 Seconds a keep-alive message to your remote-host.

if this does not work you can reduce the time.

The other way (not so secure like the first way) On the Server, open your /etc/ssh/ssh_config create if it does not exist
And add:

Host *
ServerAliveInterval 240

240 would be the amount seconds the Host will keep your SSH-Session alive.
After 240 it will close the session.
0 means do not keep alive

As i said, it's mostly better practice is to keep your client doing the keep-alive-work, and keeping your Server kinda tight.

share|improve this answer
    
I added this locally but it didn't help. I think it's already set to something similar on remote but i've asked the admin to confirm. –  Ben Jan 28 '13 at 9:14
    
i forgot, you have to restart the ssh service –  zwarag Jan 28 '13 at 9:21
    
Is there any reason why it would be timing out though? The computer next to me works fine and it's plugged into the same switch. –  Ben Jan 28 '13 at 9:27
    
Sry Ben. I can only guess from now on. Check if the watches run at the same timeserver. Set Client-Keep-Alive at 10 sek. Go to the sshd_config, set LogLevel VERBOSE and check the syslog for some interesting output –  zwarag Jan 28 '13 at 9:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.