Re: OpenSSH not closing idle sessions.
- Date: Mon, 08 Apr 2019 19:57:31 -0700
- From: Kushal Kumaran <kushal@xxxxxxxxxxxxx>
- Subject: Re: OpenSSH not closing idle sessions.
timothylegg <timothydlegg@xxxxxxxxx> writes:
> 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
Why would you have multiple SSH sessions live simultaneously? Since
you're forwarding ports, you can set it up so that only one of them can
have successfully setup the forwarding (see ExitOnForwardFailure in the
Something like this might work:
while :; do
-o ServerAliveInterval=30 \
-o ServerAliveCountMax=3 \
-o ControlPath=/tmp/ssh-%h-%p-%r \
-o ControlMaster=auto \
-o ControlPersist=yes \
-o ExitOnForwardFailure=yes \
-L <forwarding-spec> \
This will make sure the tunnel is always around, and gets reconnected
after network hiccups long enough to cause disconnection. Just set it
up to run at boot on each site.
> 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.