On 27 November 2010 16:33, <[email protected]> wrote: > I want to setup some of the hardening standards from the Center for Internet > Security (CIS), so I tried the example they have in section of SN.8 Lock Out > after 3 Failures, after adjusting it, I have the following pam system-auth > working for the most part. <snip> > after testing this it works fine for any account that doesn`t have a ssh key > set up, however if you have a ssh-key setup, you never get denied access due > to pam_tally2 lock out.(account section of pam) > I was able to verify that sshd does use account section of system-auth by > expiring an account.(at least for account pam_unix) I change the lastchg > field of the shadow file and setting password inactivity to 1, as in the > last passwd change is older then allowed. And even accounts that have ssh > keys are denied access from the account section of system-auth due to > password expired.
How are you defining a password failure with an SSH key? Supplying the wrong key or supplying the wrong passphrase? IIRC, it doesn't matter that SSH is checking the account section, as the issue with an SSH key is that it will never "fail" the auth section, because SSH keys are not checked through PAM. The reason pam_tally2 is in the auth section is because that's where it collects the information about whether the password is correct. It is in the account section simply to action the denial - so the real question (and the issue I think) is that it will never fail the auth session, so won't increment the counter and will never be denied. I'm not sure it's a bug - that is the behaviour I would expect, unless pam_tally2 can/should collect the failure status of the key from openssh itself. -- Sam _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
