query wrote: > Guys , since we are clear now that we are not behind NAT , so we can > forget now about reducing the keep-alive time Note that the same issue applies for firewalls which use connection tracking to determine which packets to allow. Ultimately, it's the connection tracking that's the issue, not NAT per se. If the router "forgets" a connection because it hasn't seen any traffic in a long time, and the result of this is that subsequent packets are silently discarded, then the connection will cease to work, resulting in a timeout occurring the next time either side tries to send data. This isn't an issue if connection tracking is only used for scheduling. > So, do you suggest now to enable to enable the ClientAliveInterval > option . Also , since ClientAliveCountMax is enabled by default with a > value of 3 , > so probably I will keep the value of ClientAliveInterval less than 300 > secs . I will probably keep it at 60 secs. So , the connection will > dropout after 180 secs if there is no response . > > Also , somewhat strange , TCPKeepAlive option is disabled in our > sshd_config file , not sure why . So , If ClientAliveInterval is > enabled , can we can leave TCPKeepAlive disabled . Is our purpose > will serve ? The main reason to disable TCP keep-alives is that they can cause a connection to be dropped unnecessarily. A secondary reason is that they will cause an on-demand link-layer connection to be opened unnecessarily, but that's less of issue nowadays. Without keep-alives, an idle TCP connection doesn't cause any packets to be sent. The physical link could be down for days, but the TCP connection will remain open so long as no packets are sent while the link is down. Enabling keep-alives will cause the connection to fail in this situation. The main purpose of keep-alives is to prevent the situation where the client system crashes, leaving the server process listening for packets which will never arive. Without keep-alives, there's no way to distinguish between a client which has permanently vanished and one which has merely been idle for a long time. The SSH keep-alives (ClientAliveInterval and ServerAliveInterval) serve a similar purpose (to force a connection to be terminated when the other end disappears without explicitly closing the connection), except that the SSH protocol prevents spoofing. This prevents the situation where an attacker "silences" one side of the connection and spoofs TCP keep-alives to prevent the server from realising that something has happened. -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> -- 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
