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 again.
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 <wool...@eeg.ccf.org> 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. >
