Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
  • Client : OpenSSH_5.1p1 Debian-5ubuntu1 (Ubuntu 9.04)
  • Server : OpenSSH_5.1p1 Debian-5 (Proxmox 2.6.24-7-pve)

I use SSH to execute commands remotely on the server (module check_by_ssh of Nagios). But SSH hangs from time to time when trying to execute commands. I can log to the server via SSH but not executing a simple 'ls'. And it seems to block from all clients from the same IP address. Authentication is not the problem, may it be made by SSH keys or password.

ssh -l root -p 2222 server.domain.tld 'ls'

Here the client debug info

debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env ORBIT_SOCKETDIR
*** skipping approx 40 env var ignored
debug1: Sending command: ls
debug2: channel 0: request exec confirm 1

It hangs there. Then after a random time, it works again (without doing anything). Killing all sshd process on the server seems to work too. It works from a Putty. I saw that some people had trouble like this due to ISP reverse DNS problem, but it does not seem to be the case here.

It can work for hours and then not work for half an hour or so.

What could explain this behaviour ?

EDIT : Seems that with -t or -T option, ssh does not hang, but I can't pass one of these options in the check_by_ssh of nagios

share|improve this question
    
Our two Proxmox hypervisor do the same thing randomly, quite allways at the same time. They are 64 bits architecture hosted remotely by OVH but no it the same bay it seems. –  Serty Oan Jun 16 '10 at 7:52
add comment

7 Answers 7

You may be hitting an SSH rate limiter on the server-side network. This is a firewall technique to block IP addresses that have too many new connection requests within a short period of time. Then the source IP is blocked for a defined period of time.

share|improve this answer
add comment

I got idea to resolve my problem from this blog. I also have very interesting problem

I got a L2vpn link (vendor provided MPLS L2) to connect my HO and branch office. all ping connectivity testings were working fine. When i ssh using debian server from HO to a debian server at client side i can log in to that server but after remotely ssh login to branch server i was unable to run ifconfig, htop or ps -ef commands. When i apply thoses commands the session freezes. Evn that i check it from windows pc using putty the result was same. Interesting thing is that when i use putty manager and ssh via that application from win 7 pc it was working fine. After reading this blog i got mpls mtu information from service provider and try the same scenario with different mtu size on source debian server interface at HO. Finally mtu sizes from 1440 to 1470 was working fine where as defaults mtu size 1500 was not working. Conclusion: the both end debian server's mtu size was default ie 1500 but in the mid way where service providers MPLS L2vpn mtu size was miss matching. thanks

share|improve this answer
    
MTU seems like a very likely culprit in these cases. I had the same issues which were resolved by changing the server MTU to low value. Read more at snailbook.com/faq/mtu-mismatch.auto.html I think that while @aleksandr levchuk answer is plausible, it's not very likely. –  stricjux Jul 9 at 10:04
add comment

Check the ssh on the server side. You may "strace" the created process / mail sshd process and see what syscalls is it calling. This should give you more info on what is it doing.

Also try "touch /tmp/randomfile" and see if the hangs happens after it get created or afterwards.

share|improve this answer
    
What should I look for in the strace ? Does not look different when I just log via ssh or execute a command touch /tmp/randomfile hangs but no file is created –  Serty Oan Jun 2 '10 at 12:04
add comment

Have you checked to make sure there arent any PAM errors? just because it works from putty doesnt mean authentication isnt the problem.

share|improve this answer
    
The authentication is not the problem because the debug log of client and server show that authentication has passed. –  Serty Oan May 28 '10 at 14:38
    
is the directory being listed local to the machine it is running on, and are there any disk/filesystem errors? –  Devnull May 28 '10 at 19:36
    
(Sorry did not see your answer) It is local to the machine, no disk errors. It hangs whatever command is done, may it be a ls or a touch etc –  Serty Oan Jun 2 '10 at 12:06
    
has this machine been renamed or readdressed since it was installed? –  Devnull Jun 2 '10 at 14:33
    
Not renamed nor readdressed. And what's strange is that it makes the same on another proxmox server, but not at all on other servers nor vms on those proxmox. –  Serty Oan Jun 2 '10 at 14:47
show 4 more comments

Could there be anything in the user shell environment deadlocking or delaying on open? The -t/-T workaround and closing other ssh sessions clearing it up sounds like something acquiring a lock with the assumption it's the only process.

share|improve this answer
    
Indeed, any idea of options/config that could remove those locks ? –  Serty Oan Sep 6 '10 at 7:50
    
Look through your shell rc files for anything non-standard. Assuming bash, ~/.bashrc, ~/.bash_profile, and the corresponding /etc/bash* files if it happens for multiple users. Perhaps you can compare with another system (or another user if it's only to one user)? –  Jeremy M Sep 16 '10 at 1:50
add comment

I've experienced the same when having MTU problems. Using ciscos ipsec client-to-site, and then openvpn on top of that. Basically any packet with the size of 1500 bytes would freeze the session.

share|improve this answer
    
And did you find a solution ? –  Serty Oan Oct 5 '10 at 9:12
    
Set a lower MTU in the Cisco VPN client :-) –  3molo Oct 5 '10 at 9:14
add comment

I had similar problem. Both client's and server's MTU were 9000. After I lowered client's MTU to 1500 problem was gone.

share|improve this answer
    
Both MTU are at 1500 here, but thanks –  Serty Oan Oct 14 '10 at 8:22
add comment

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.