Seems to be specific to Solaris 10 implementation of SSHD. The first method tested in the PAM chain is sshd-none, this is not handled by the standard pam.conf so it is handled by the "other" catch-all method in pam.conf. The default method updates the /etc/shadow record for the user with an incremented auth failure flag. This occurs before the pam chain processes sshd-kbdint, on which the securid module is triggered.
Adding the following line to the pam.conf causes the sshd-none to be handled, which in turn stops the auth failure flag from incrementing.
sshd-none auth optional pam_deny.so.1
** This is a workaround only. The workaround appears to sole the problem but should be used with caution
Sun has published the following articles on their customer KB:
Bug ID: 5033461 Synopsis: default /etc/pam.conf should have entry for sshd-none with pam_deny.so.1
State: 6-Fix Understood
The default system /etc/pam.conf should have an entry for sshd-none thus: sshd-none auth required pam_deny.so.1 sshd-none account required pam_deny.so.1 sshd-none session requried pam_deny.so.1 sshd-none password required pam_deny.so.1
Bug ID: 6365483
Synopsis: Re-open of 4890177: sshd always increments /etc/shadow auth failure field
This is a reopen of bug 4890177: sshd always increments /etc/shadow auth failure field
This problem (re-)appeared in Solaris 10 GA (s10_74L2a) using following testcase:
1) on sshd server, /etc/security/policy.conf: ... LOCK_AFTER_RETRIES=YES CRYPT_DEFAULT=__unix__ CRYPT_ALGORITHMS_ALLOW=1,2a,md5
2) 2 users: user1 and user2 a)for each user: # ssh-keygen -t dsa b)copy ~/.ssh/id_dsa.pub of user1 to ~/.ssh/authorized_keys user2 (and vice versa)
As one can see, the "none" auth method is always run with the empty string as the password, and this is what is causing the counter to increment.
Date Modified: 2005-12-20 14:54:09 GMT+00:00
From the comments:> Add the following lines to /etc/pam.conf> sshd-none auth required pam_deny.so.1> sshd-none account required pam_deny.so.1> sshd-none session required pam_deny.so.1> *** (#1 of 2): 2005-12-20 08:55:03 CST firstname.lastname@example.org