Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

PCI requirement 8.5.15 states: "If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal."

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.

share|improve this question
I'm really not trying to be pedantic, but I think you need to define 'idle' for us: idle = no user input? or idle = no output to user? The solutions required will be different. –  pjz Jul 7 '09 at 3:27
idle == no user input –  Insyte Jul 7 '09 at 15:28

5 Answers 5

up vote 1 down vote accepted

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.

share|improve this answer
Interesting idea; I may end up with something like this. However I think I'd experience a rebel uprising if I forced everyone to start working inside screen. –  Insyte Jul 7 '09 at 15:31
With autodetach off, they'd basically never notice. If you included something like 'defescape "^ "' (or at least to a more obscure control sequence than ^A) it'd be impossible or unlikely for them to actually treat screen like screen; they'd just see "screen" if they echo'd the TERM var, and even that you could change to vt100. –  freiheit Jul 7 '09 at 17:21

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.

share|improve this answer
+1 -- This is my thought, as well. Set "ClientAliveInterval 900" (15 min = 900s) and "ClientAliveCountMax 0" in /etc/ssh/sshd_config and restart sshd and that should do it. –  Geoff Fritz Jul 6 '09 at 23:31
That timeout can be easily circumvented by a client application sending "keep-alive" packets though. –  David Spillett Jul 6 '09 at 23:46
This simply doesn't do what's wanted at all. The ClientAliveInterval causes the sshd server to (essentially) send a ping through the ssh channel to see if the client is still there. It's not useful for idling out the user. –  freiheit Jul 7 '09 at 17:13

Under BSD i'm using idled by Michael P. Crider

Quote from description

Idled is a daemon that runs on a machine to keep an eye on current users. If users have been idle for too long, or have been logged on for too long, or have logged in too many times, it will warn them and log them out appropriately.

I think you also can find it in linux repositories.

share|improve this answer

The following, added to your sshd config, will simply close the SSH connection after 15 minutes of inactivity:

ClientAliveInterval 900
ClientAliveCountMax 0
share|improve this answer

The right answer here is

export TMOUT=900

in .bash_profile

(invoking screen isnt a direct way to deal with this problem)


share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.