Re: OpenSSH not closing idle sessions.
- Date: Mon, 8 Apr 2019 19:14:34 -0500
- From: timothylegg <timothydlegg@xxxxxxxxx>
- Subject: Re: OpenSSH not closing idle sessions.
I'm the only user that will be angry at being disconnected. There is
no easy way to explain the reasoning; I've rewritten this paragraph
three times because it was too long. I have two residences and one
has a port forwarding issue. I want to make an SSH tunnel to the
other site. If I am at one place for multiple weeks, it's asking too
much for the SSH tunnel to stay live that long (I've seen many
complaints of SSH connections dropping). I want to put it on a
periodic cron job, but if I don't answer into the tunnel within 30
minutes, it becomes idle and drops off. Every hour a new tunnel is
initiated. The old session must either be closed or expire else I'll
have multiple SSH sessions live simultaneously. I don't want to
travel with three laptops and 8 USB hard drives in carry on luggage
My next flight is in May. I'm doing a simulation with two VMs, but in
reality, there will be two raspberry PIs doing the gatekeeping for me.
On Mon, Apr 8, 2019 at 12:39 PM Greg Wooledge <wooledg@xxxxxxxxxxx> wrote:
> On Mon, Apr 08, 2019 at 12:25:28PM -0500, timothylegg wrote:
> > I need to have the session expire and the ssh client terminate after
> > an idle time.
> Most people want the exact opposite of that.
> Basically, what you're asking for is directly hostile to any kind of
> sane operation of a computer.
> > ClientAliveInterval 5
> > ClientAliveCountMax 1
> Those settings are used for two purposes. The first is to allow ssh or
> sshd to terminate when the network connection has been lost. The second
> is to keep sending "I'm still here" messages through the network connection
> so that a NAT gateway will not drop the session due to inactivity.
> So, if you wanted to achieve the exact opposite of your stated goal
> (assuming a NAT is involved somewhere along the way), you've succeeded.
> I'm not aware of any "features" to cause ssh to terminate when idle, at
> the ssh transport level.
> If all you want to do is terminate the user's shell (and thus their
> ssh connection, ultimately) when the user is sitting idle at the shell
> prompt for too long, you could use the shell's TMOUT variable.
> Of course, that won't disconnect the user's idle vim or mutt command.
> That would result in data loss.
> TMOUT only works when idling at a shell prompt, and it requires the user
> to sign up for this "feature" by setting that variable (or neglecting
> to unset it, if someone tries to set it in a global shell file like
> Perhaps you could reframe your question in a way that makes sense in
> a universe where the data loss from just arbitrarily killing users'
> text editors and other stateful applications is a concern. Start by
> stating why you're trying to do this, who's making you do this, who's
> going to handle the angry users, who's going to compensate them for
> their data loss, etc.