[sf-lug] keep alive time for an ssh connection

[Michael Paoli]

> Date: Fri, 19 Dec 2008 16:28:00 -0800 (PST)
> From: Alex Kleider <a_kleider at yahoo.com>
> Subject: [sf-lug] keep alive time for an ssh connection
> To: Linux userGroup <sf-lug at linuxmafia.com>
>
> I have found that when using PuTTy as an ssh client from my office
> computer to log onto (via the internet) one of my linux computers the
> connection seems to remain established indefinitely. When I log onto
> that same computer from another site using a linux computer, the
> connection seems to time out after a period of inactivity. I've found
> nothing in the ssh_config file that might control this behavior.
> Does anyone know how this behavior is controlled?
> i.e. how is it decided how long an ssh connection will remain
> established during inactivity?

For sufficiently non-ancient ssh client, there's not only TCPKeepAlive,
but also ServerAliveInterval, etc.

The timeouts/disconnects most commonly happen, when a NAT/SNAT,
firewall, or other network device (including also software
implementations) drops, or drops state information of, the TCP
connection.

One common workaround is TCPKeepAlive.  One disadvantage with
TCPKeepAlive, is that some network devices that are looking to drop
inactive TCP connections also want to drop and consider TCP connections
inactive when their only traffic is TCPKeepAlive traffic.

ServerAliveInterval, etc., has the advantage of being within ssh, and
thus generally encrypted and not visible to the network devices as to
exactly what it is - i.e. they can't really tell if it's some other data
traffic, or ssh protocol ServerAlive traffic within the ssh data, ...
so, thus they don't discriminate, and they'll keep the connection open -
whereas in the case of only TCPKeepAlive traffic, they may discriminate
and drop the connection.

Not sure if PuTTY yet has ServerAlive capabilities.  A low tech
work-around - which can also often defeat other timeout mechanisms is
just having something that generates a bit of traffic once in a while,
e.g.:
$ while :; do sleep 300; echo -en '\007'; done &

One drawback with ServerAlive and TCPKeepAlive (or for that matter,
almost any traffic) is that they can cause a connection to be dropped
if connectivity is temporarily dropped for a while - whereas without
ServerAlive and TCPKeepAlive, the connection may continue to work when
connectivity is restored - that tends to be the case if there's no
traffic when the connectivity is lost, or there isn't "too long" of a
time period between when traffic is attempted and the connectivity is
restored.  At least some of that behavior (e.g. how long to wait on
lost connecivity before giving up) is relatively tunable on the ssh
client.

references:
ssh_config(5)