Enabling ServerAliveInterval by default

Bob Proulx bob at proulx.com
Mon Dec 17 06:21:58 EST 2007

Nadav Har'El wrote:
> I'm having a very hard time believing that I have been the only person who
> in the course of the last few years found it harder and harder to keep
> non-LAN ssh connections active without being disconnected after a few minutes
> of inactivity. I've seen this problem on several combinations of client and
> server networks.

I personally am not seeing this problem with any of the connections
that I am keeping online for long periods of time.

> > Personally, I have situations where I like ServerAliveInterval, and other
> > situations where it isn't needed, and is actually interfering with the
> > way I use SSH.  So I need to adapt the defaults either way.
> I am curious - how does ServerAliveInterval (again, with a large
> ServerAliveCountMax, not the default 3) interfer with the way you use SSH?

One of the issues with setting a "keepalive" diddle is that it is also
a "makedead" diddle.  If the connection is not online at that moment
then the diddle packet will cause the connection failure to be noticed
and will make it die.  This causes many people to not refer to this so
much as a keepalive but as a makedead.  It makes the connection dead.
Note that BatchMode sets keepalives automatically.

Many people who now have connections that stay alive okay without a
diddle packet would, if it were globally enabled, find that their
connections die because the network connection timed out at times that
they did not care about using it.  The diddle would make their
connections dead.  Without the diddle then the connection only dies if
it is offline when real data is needed to be transferred.  It will
survive brief periods of the network being offline when nothing is
happening.  It only has problems if there are real problems.  With a
forced keepalive diddle packet sent periodically it may die due to
synthesized data.  This may happen at times when nothing would have
been active without the keepalive setting and the connection would
have survived it okay.

There are two valid sides to this problem.  There is no clear solution
that solves both problems at the same time.  Neither is clearly right
with the other clearly wrong.  This is what makes it a religous war
between the two opposing viewpoints.  There is no single right answer.
It is a value judgement as to which one is more important or more
common than the other one.  In these situations the status quo is
often the path of least resistance because it thrashes the least
number of people.


More information about the openssh-unix-dev mailing list