Sam,
first let me say thanks for your time and reply
and now back to the topic
I`am not keeping track of ssh key failures, since sshd doesn`t use pam for authenication when authenicating with ssh keys, but sshd will still use pam for account authorization, its at this phase I would expect pam_tally2 to deny access, just like pam_unix.so does for an expired account.
so its here that I make the assumption that just having 'account required pam_tally2.so' would check to see if the account is allowed or should be denied due to failed logins.
It would seem that pam_tally2 is depend on the auth section of pam too, and not more modular, like pam_unix.so
where when sshd authenicates a user with a ssh key it still checks account authorization from pam_unix, like account expired and will deny access if the account is expired.
Thanks
John
-------- Original Message --------
Subject: Re: [rhelv5-list] rhel5 pam (tally2) and ssh
From: Sam Sharpe <[email protected]>
Date: Sat, November 27, 2010 7:22 pm
To: "Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list"
<[email protected]>
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
Subject: Re: [rhelv5-list] rhel5 pam (tally2) and ssh
From: Sam Sharpe <[email protected]>
Date: Sat, November 27, 2010 7:22 pm
To: "Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list"
<[email protected]>
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
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
