Re: Preventing SSH timeouts . Some clarification needed

[Glynn Clements <glynn@gclements.plus.com>]

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@gclements.plus.com>