PCI-DSS 3.0 requirement 8.1.8 states: "If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session." Same was in PCI-DSS 2.0 requirement 8.5.15.
The first, and most obvious, way to deal with ssh sessions that are idling at the bash prompt is by enforcing a read-only, global $TMOUT
of 900. Unfortunately, that only covers sessions sitting at the bash prompt. The spirit of the PCI spec would also require killing sessions running top/vim/etc.
I've considered writing a */1 cron job that parses the output of "/usr/bin/w" and kills the associated shell, but that seems like a blunt instrument. Any ideas for something that would actually do what the spec requires and just lock the terminal? I've looked at away
and vlock
; they both seem great for voluntarily locking your terminal, but I need a cron/daemon task that will enforce locking.
Could you put "exec screen -R" in .bash_profile and "idle 900 lockscreen" in .screenrc to solve this? That'd automatically reattach to their screen session if it's still there and create a new one if it isn't, but lock the screen if it's idle for 900 seconds.
I believe users could disable the idle, though...
Alternately: just plain "exec screen" and also "autodetach off" in .screenrc so that their sessions die if they get disconnected.
The following, added to your sshd config, will simply close the SSH connection after 15 minutes of inactivity:
It is essential to include
ClientAliveCountMax 0
to prevent the server from sending "client alive messages" to the SSH client.Under BSD i'm using idled by Michael P. Crider
Quote from description
I think you also can find it in linux repositories.
Does sshd's IdleTimeout setting do what you want? I haven't test it with users using top, but it should work for vim or things which aren't sending data.
The right answer here is
export TMOUT=900
in .bash_profile
(invoking screen isnt a direct way to deal with this problem)
http://linux.die.net/man/1/bash