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.
Best Answer
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.