Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

although this is not a real programming question perhaps anyone has any idea regarding my problem.

It's pretty weird. When I remotely connect one of our ubuntu servers per ssh the connection can be established without any problems.

I log in and enter something that produces output on the console like "ls -al". Then the connection just hangs. If I enter "ls" it shows me the output. If I enter "dmesg" session crashes too.

There's nothing in the servers log and the terminal on my side doesn't recognize the connection being closed it just hangs.

Now I wonder if this could be Firewall-Related. If there's to much output sent back it crashes.

Or maybe one of our programmers messed up something. I really don't know in which direction I can try to track this problem. Any ideas on this? I just can't understand what is happening and if it's related to network problems or system misconfiguration....I can't see why there's a difference between "ls" and "ls -al" or "dmesg". And the login produces a lot of output too on the screen but it always works.

Ok I just found out about and posted my question there. This can be deleted because it's off topic here. Thx anyway!

share|improve this question

migrated from Sep 30 '11 at 17:23

This question came from our site for professional and enthusiast programmers.

what happens when you try ls -a or ls -l ? (only trying one switch at a time: -l is long format, -a shows all files) – Piskvor Sep 30 '11 at 14:38
I will try that and report back, thx! – netsky Sep 30 '11 at 14:41
Its probably firewall related. You wouldn't happen to be dropping ICMP, in particular ICMP fragmentation needed messages, would you? (BTW: this question will hopefully be moved to Serverfault—where it is on-topic—soon. You don't need to do anything, the moderators here will take care of it) – derobert Sep 30 '11 at 14:58
I've had this at some point when connecting from a modern OpenSSH client to ancient OpenSSH server, on Solaris IIRC. Version of the server and the OS could be relevant here. You should add them. Also try running the OpenSSH server in debug mode (i.e. not going to background/daemonize) and run the client in debug mode as well. This should give you a wealth of information and has helped me many times to figure out SSH connection problems. – 0xC0000022L Sep 30 '11 at 17:32

What you've likely stumbled upon is a PMTU problem.

Many devices have a Maximum Transmission Unit(MTU) which is the maximum size of the packet they can send. If the device sees a packet beyond this threshold it will break it up into smaller parts, but some packets have a special flag that says Don't Fragment(DF). These packets are dropped and a ICMP message is sent to the sender so that the send can resize the packet itself.

In your case it looks like there is something between the SSH server and you that is dropping these packets and not telling the server. If you have a packet dump of the connection you will probably see packets missing. There is a tool on Linux called tracepath that lets you see the mtu of all the hops on the way to the server.

To work around this issue you should add an iptables rule such as the following to the network your server resides in:

iptables -A INPUT -d x.x.x.x/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
share|improve this answer

You can use tcpdump to see if it is a firewall. Just make sure you filter port 22, to/from your remote host and if the packets stop going through, you know it's a network issue.

Another thing is to clear your $HOME/.${SHELL}rc file to make sure there is nothing in there that causes an error at the shell access. In particular check your TERM variable.

share|improve this answer

You have a firewall between you and the target host that has strict tcp sequence checking enabled. A delay in one or more packets traversing the network causes packets to arrive out of order. The firewall is assuming that this is an an attack of some type (examples of attacks that would match this are session hijacking and session replay, but there are others as well). The firewall then destroys the session. The following packets arrive without a SYN to establish a session so the firewall drops them too.

Incidentally, what kind of firewall do you have between you and the target?

share|improve this answer

Your Answer


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