Web lists-archives.com

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
> /etc/profile).
> 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.