Dan Yefimov wrote: > On Wed, 8 Oct 2008, Tomas Mraz wrote: > >> On Wed, 2008-10-08 at 01:25 +0400, Dan Yefimov wrote: >>> On 07.10.2008 2:40, Max Bowsher wrote: >>>> I know about the special behaviour of "!" in a password field when SSH >>>> is managing authentication itself. My point is that this special >>>> behavior does NOT exist any more when SSH is authenticating via PAM - >>>> but I want it to! >>>> >>> If SSH authentication does be performed via PAM (so called keyboard-interactive >>> authentication), you do have that behaviour. But, IIRC, you perform >>> authentication with SSH public key, which completely bypasses PAM infrastructure >>> at the authentication stage regardless of 'UsePAM yes' setting, thus the result >>> you observe. PAM has nothing to do with that. Please carefully read sshd_config >>> manual. >> Not really - sshd will call pam_acct_mgmt() even in case of public key >> authentication. The problem is pam_unix checks just the expiration dates >> of the shadow entry, not the password hash field contents. >> > Password hash entry is implicitly checked at pam_authenicate() time, not at > pam_acct_mgmt() time. But pam_authenticate() is not called during public key > authentication. That's exactly what I said. No, you're missing something: A password hash that begins with a ! character, by mostly undocumented but fairly widespread convention, has a meaning beyond mere authentication - it denotes a completely locked account. This semantic is expected by traditional Linux tools such as those built from the 'shadow' source package of most Linux distros, and extended tools such as Debian's 'adduser', which makes a distinction between a disabled *account* and a disabled *password* and maps this to the "!" vs. "*" convention. >> I think we should do the same as sshd on Linux without PAM enabled - it >> will reject just the accounts with password hash that starts with the >> '!'. We would not reject the accounts with '*' in the password hash in >> the shadow entry. >> > SSHD rejects such accounts while performing password verification. If the > password hash for password provided by user isn't equal to what is contained in > shadow, access is denied. That's simple. I think there is no reason to > duplicate the job of auth stack compulsorily, but if somebody wants such > duplication, let him specify special pam_unix command line option in account > stack. This isn't about password verification, or duplication of anything. It is about implementing the semantics for the password hash field that I describe above, which whilst admittedly mostly undocumented other than in the behaviour of various common tools, are widespread in Linux software other than PAM. It might make sense for this behaviour to configurable via a pam_unix command line option, because otherwise it may be too incompatible to make in a 1.0.x release of PAM - I am not familiar with the PAM project's compatibility policy. Were it not for compatibility concerns, I would suggest that it should be unconditional, as it is a standard facet of "traditional unix" security as applied to Linux, which is exactly what pam_unix is all about. Max.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
