Enabling ServerAliveInterval by default

[Peter Stuge]

On Sun, Dec 16, 2007 at 08:56:25PM +0200, 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 don't find it hard.

If you are running the ssh client, there is ServerAliveInterval and
ServerAliveCountMax.

If you are running the sshd, there is ClientAliveInterval and
ClientAliveCountMax.

Set them up so that OpenSSH works for you the way you want it to.


On Mon, Dec 17, 2007 at 10:30:23AM +1100, Philip wrote:
> +1 here - it also took me a long while to figure out what was going
> on when I had this problem.

This is of course unfortunate. But please keep in mind that what you
are experiencing is not originating from or caused by OpenSSH (or any
other application for that matter) and thus that is the wrong place
to _solve_ the problem.


> I wish it had been a default years ago.

I believe in obvious defaults. That is impossible in this case.


> It's easy enough to change the defaults on machines under your own
> control, but the biggest problem I had was convincing the
> administrators of remote systems I had to use to change their
> sshd_config.

Again, there are some options also in the client that will send extra
IDLE packets.


> For some systems, we set up a shell alias:
> 
> alias ka='while [ 1 ]; do echo -n "."; sleep 120; done'
> 
> Then of course you have to remember to run that each time you stop
> actively using a session. In short: PITA.

If you want to get creative like this there is a large number of
workarounds that could be concieved. The channel and subsystem
concepts in SSH could be used to do stuff. All automated.

It will be easier to change your local config though.


> Regarding Bob Proulx's discussion of "make-dead" vs. "keep-alive" -
> it's a point worth considering. I've usually set an interval of a
> few minutes, and a very large ServerAliveCountMax so that it's used
> only for keeping the connection alive, not disconnecting
> temporarily-missing clients. Is this something worth considering as
> a default?

I don't think so, because sending packets like this on a dead
connection will (naturally) also affect the OS TCP connection
state machine, and then you would suddenly need to be root everywhere
in order to fully control what and how connections should be kept
alive. (Because now it's a kernel setting.)


On Mon, Dec 17, 2007 at 12:24:43PM +1100, Philip wrote:
> In the position where I mainly encountered such problems, we had to
> consider:
> - language barriers - I only speak English, which makes it hard for
> me to communicate the issue

If root does not understand english I see how it can be difficult for
them to work with the configuration files and corresponding
documentation too. I would argue this falls under competence.


> - political issues - inter-departmental, vendor/purchaser,
> international

As much as I would like them to, it is quite impossible for OpenSSH
configuration defaults to abstract these issues.


> - "face" issues - senior admins often don't take kindly to some
> foreigner telling them how to do their jobs

One can ask in many ways. The admin is supposedly there to support
users, and thus it should be possible for users to formally, or even
informally, submit a change request so that they can do their job
better. If that's not the case, I would argue that this is a
political issue. See above.


> - competence issues - often, Windows admins have had Unix boxes
> foisted on them with little or no training

So you want an AI configuration file generator? I strongly believe
that no effort whatsoever should be spent on trying to solve this
problem since it will be futile. Better just educate people!


> - type of network connection - the admins are usually on the same
> LAN as the SSH hosts, so they never see the problem themselves

See face issues. root should care.


> I agree, we should try to get everyone to do The Right Thing, but
> sometimes it just isn't going to happen. Sensible defaults are
> useful in such cases (defining "sensible" is going to be the
> problem here, I suspect).

Certainly if a single set of defaults must be "sensible" for all
possible combinations of {language,political,competence} issues.


//Peter