Thanks for the suggestion . On Tue, Jun 8, 2010 at 4:09 PM, Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> wrote: > > query wrote: > >> One work around I could see is adding a timeout value using >> ClientAliveInterval option in /etc/ssh/sshd_config on the server side >> . Assume I have set the timeout value to 300 . >> >> >> " The above option as per the sshd man page tells that it sets a >> timeout interval in seconds after which if no data has been received >> from the client, sshd(8) will send a message through the encrypted >> channel to request a response from the client. " >> >> Let's take a situation where the SSH client is 100% busy or idle and >> it had communicated to the server for around 300 seconds , then in >> this case if the above option is there , the server should send a >> message to the client after 300 secs . The following two scenarios are >> coming to my mind. >> >> 1) if the server is also 100% busy during that time and could not >> send the message to the client , will the ssh connection will be >> dropped . >> 2) or Suppose the server was somewhat free after 350 secs , in that >> case will it drop the connection or it will send a message to the >> client to check whether the client is active or not since it could not >> send the message at 300 s as it was busy during the time . > > According to the sshd_config(5) manpage, the server will close the > connection after ClientAliveCountMax messages (default value: 3) have > been sent. > > I can't see how this can be caused by load. If you haven't yet enabled > ClientAliveInterval, then the connection isn't being closed by sshd > but by the kernel, due to TCP keep-alives not being acknowledged. okay...that may be the cause . The client host was also busy because of which TCP keep-alive were not acknowledged. > > By default, the kernel doesn't start sending keep-alives until the > connection has been idle for 2 hours, after which it sends 9 probes at > an interval of 75 seconds, so the system would need to be > non-responsive for over 11 minutes. And the responses are generated by > the kernel, so they'll be sent even if the process is suspended. > > As Michal suggests, the most likely reason for this is a NAT timeout. > If you're using NAT, you probably want to set the keep-alive time > (/proc/sys/net/ipv4/tcp_keepalive_time) to a value less than the NAT > timeout. Even then, that will only work for programs which enable > keep-alive (ssh and sshd both do by default; this is controlled by the > TCPKeepAlive option). How to determine the value of NAT timeout . Is it at the host level or the device where NATing is implemented . I was able to find the keepalive timeout value at the host . ==== $ sudo sysctl -a | grep -i keepalive net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 ===== Most likely I am not behind NAT , I will confirm it tomorrow . If that is the case , then which should I consider to increase the timeout value. The kernel timeout value or implement either TCPKeepAlive option or the ClientAliveInterval interval . TCPKeepAlive option is somehow disabled in the sshd config file . Please clarify regarding this. > > -- > Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> > Once again , thanks all --Zaman -- To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
