[VLOCK] User Account gets locked (faillock) when a locked vlock session is terminated

20 views
Skip to first unread message

Sven

unread,
Feb 20, 2020, 5:33:25 AM2/20/20
to tmux-users
Hi,

i configured tmux as follows (/etc/tmux.conf on RHEL 7.7)

set -g lock-command vlock
set -g lock-after-time 900

After 900s my session is being locked and i can reauthenticate without problems as long as my SSH session is active. BUT when i close my ssh-session (via TMOUT or just by closing Putty) my user account is getting locked (via pam_faillock).

Feb 19 13:50:11 host1 vlock[31209]: Locked tty on pts/0 for user1 by (uid=5100)
Feb 19 13:50:50 host1 sshd[10687]: pam_unix(sshd:session): session closed for user user1 ## <--- i manually killed the SSH Session
Feb 19 13:50:50 host1 vlock[31209]: pam_unix(vlock:auth): conversation failed
Feb 19 13:50:50 host1 vlock[31209]: pam_unix(vlock:auth): auth could not identify password for [user1]
Feb 19 13:50:52 host1 vlock[31209]: pam_unix(vlock:auth): auth could not identify password for [user1]
Feb 19 13:50:54 host1 vlock[31209]: pam_unix(vlock:auth): auth could not identify password for [user1]
Feb 19 13:50:54 host1 vlock[31209]: pam_faillock(vlock:auth): Consecutive login failures for user user1 account temporarily locked


$ cat /etc/pam.d/vlock
#%PAM-1.0
auth       include      system-auth
account    required     pam_permit.so

$ cat /etc/pam.d/system-auth
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=14400 fail_interval=900
auth include system-auth-ac
auth [default=die] pam_faillock.so authfail silent audit deny=3 even_deny_root unlock_time=14400 fail_interval=900
account required pam_faillock.so
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac


I'm not a pam expert but i hope someone can point me to the right direction!?

regards
sven

Nicholas Marriott

unread,
Feb 20, 2020, 5:37:43 AM2/20/20
to Sven, tmux-users
Did you close the terminal containing vlock? vlock should exit in this
case, if it doesn't it is a vlock bug. Can you see it still running?


On Thu, Feb 20, 2020 at 02:33:25AM -0800, 'Sven' via tmux-users wrote:
> Hi,
> i configured tmux as follows (/etc/tmux.conf on RHEL 7.7)
> set -g lock-command vlock
> set -g lock-after-time 900
> After 900s my session is being locked and i can reauthenticate without
> problems as long as my SSH session is active. BUT when i close my
> ssh-session (via TMOUT or just by closing Putty) my user account is
> getting locked (via pam_faillock).
> Feb 19 13:50:11 host1A vlock[31209]: Locked tty on pts/0 for user1 by
> (uid=5100)
> Feb 19 13:50:50 host1A sshd[10687]: pam_unix(sshd:session): session closed
> for user user1 ## <--- i manually killed the SSH Session
> Feb 19 13:50:50 host1A vlock[31209]: pam_unix(vlock:auth): conversation
> failed
> Feb 19 13:50:50 host1A vlock[31209]: pam_unix(vlock:auth): auth could not
> identify password for [user1]
> Feb 19 13:50:52 host1A vlock[31209]: pam_unix(vlock:auth): auth could not
> identify password for [user1]
> Feb 19 13:50:54 host1A vlock[31209]: pam_unix(vlock:auth): auth could not
> identify password for [user1]
> Feb 19 13:50:54 host1A vlock[31209]: pam_faillock(vlock:auth): Consecutive
> login failures for user user1 account temporarily locked
> $ cat /etc/pam.d/vlock
> #%PAM-1.0
> authA A A A includeA A A system-auth
> accountA A requiredA A A pam_permit.so
> $ cat /etc/pam.d/system-auth
> auth required pam_faillock.so preauth silent audit deny=3 even_deny_root
> unlock_time=14400 fail_interval=900
> auth include system-auth-ac
> auth [default=die] pam_faillock.so authfail silent audit deny=3
> even_deny_root unlock_time=14400 fail_interval=900
> account required pam_faillock.so
> account include system-auth-ac
> password include system-auth-ac
> session include system-auth-ac
> I'm not a pam expert but i hope someone can point me to the right
> direction!?
> regards
> sven
>
> --
> You received this message because you are subscribed to the Google Groups
> "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tmux-users+...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/tmux-users/594d149a-ad3d-43b7-a7f6-c6bc4b584813%40googlegroups.com.

Sven

unread,
Feb 20, 2020, 7:50:03 AM2/20/20
to tmux-users
yes, it's still active after closing the ssh-connection. i need to open a new ssh-session, login as root (because "user1" is locked), kill the vlock-process and finally reset the faillock record of "user1".

Nicholas Marriott

unread,
Feb 20, 2020, 7:57:47 AM2/20/20
to Sven, tmux-users
What if you enable ssh keep alives? Put this in .ssh/config:

TCPKeepAlive yes
ServerAliveInterval 10

vlock should die on SIGHUP, I don't see it ignoring it in the code.
However, this can take a long time on a TCP connection.
> --
> You received this message because you are subscribed to the Google Groups "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tmux-users+...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/257297e1-0ceb-4647-bbf5-9809fcfcdfad%40googlegroups.com.

Sven

unread,
Feb 20, 2020, 11:16:30 AM2/20/20
to tmux-users
enabling of ssh keepalives on the client side changed nothing important (except of keeping the ssh session alive). if i close the ssh session manually (kill, force close putty etc.), vlock stays alive and faillock locks my user account.

BUT...

when i vlock the session manually (just by typing "vlock") i can force close my ssh-session and reconnect without problems (my user account is not locked by faillock). the difference is that i got a new pty (pts/1). a process of the old vlock process (for pts/0) still exists (ps -ef).
 is this an expected behaviour?

at the moment i "autostart" tmux/vlock via .bashrc. i searched the web and found dozens of possibilities. i decided to add the following code to ~/.bashrc:

if [ "$SSH_TTY" ]
then
  '[ -n "$PS1" -a -z "$TMUX" ] && exec tmux'
fi


regards
Sven




Am Donnerstag, 20. Februar 2020 13:57:47 UTC+1 schrieb Nicholas Marriott:
What if you enable ssh keep alives? Put this in .ssh/config:

TCPKeepAlive yes
ServerAliveInterval 10

vlock should die on SIGHUP, I don't see it ignoring it in the code.
However, this can take a long time on a TCP connection.


On Thu, 20 Feb 2020 at 12:50, 'Sven' via tmux-users
<tmux-...@googlegroups.com> wrote:
>
> yes, it's still active after closing the ssh-connection. i need to open a new ssh-session, login as root (because "user1" is locked), kill the vlock-process and finally reset the faillock record of "user1".
>
>
>
> Am Donnerstag, 20. Februar 2020 11:37:43 UTC+1 schrieb Nicholas Marriott:
>>
>> Did you close the terminal containing vlock? vlock should exit in this
>> case, if it doesn't it is a vlock bug. Can you see it still running?
>>
> --
> You received this message because you are subscribed to the Google Groups "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tmux-...@googlegroups.com.

Nicholas Marriott

unread,
Feb 20, 2020, 11:34:11 AM2/20/20
to Sven, tmux-users
I'd expect the pty to stay around until the tmux client exits and it
shouldn't exit until vlock does.





On Thu, Feb 20, 2020 at 08:16:30AM -0800, 'Sven' via tmux-users wrote:
> enabling of ssh keepalives on the client side changed nothing important
> (except of keeping the ssh session alive). if i close the ssh session
> manually (kill, force close putty etc.), vlock stays alive and faillock
> locks my user account.
> BUT...
> when i vlock the session manually (just by typing "vlock") i can force
> close my ssh-session and reconnect without problems (my user account is
> not locked by faillock). the difference is that i got a new pty (pts/1). a
> process of the old vlock process (for pts/0) still exists (ps -ef).
> A is this an expected behaviour?
> at the moment i "autostart" tmux/vlock via .bashrc. i searched the web and
> found dozens of possibilities. i decided to add the following code to
> ~/.bashrc:
> if [ "$SSH_TTY" ]
> then
> A '[ -n "$PS1" -a -z "$TMUX" ] && exec tmux'
> email to tmux-users+...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/tmux-users/b661b91d-0804-4c24-8eb8-b82f4e62f9da%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages