Article Number
000025252
Applies To
ACE/Agent for PAM 5.3.4
Solaris 10 SSHD
Issue
PAM Agent Solaris 10 sshd allows SecurID challenged user with blank Unix password access without challenge
Unix user account belongs to group configured to be SecurID challenged
Unix password has been set to blank or is empty
User enter username and is instantly granted access without challenge.
Cause
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 handler grants access to the system. This occurs before the pam chain processes sshd-kbdint, on which the securid module is triggered.
Resolution
Adding the following line to the pam.conf causes the sshd-none to be handled, which in turn forces the sshd to process the next method in the pam chain before access is granted:
sshd-none auth optional pam_deny.so.1
** This is a workaround only. The workaround appears to solve the problem but should be used with caution
Notes
Sun have 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
Category: ssh
Subcategory: pam
State: 6-Fix Understood
Description:
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
Category: ssh
Subcategory: pam
State: 11-Closed
Description:
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)
# cat /etc/shadow
...
user2:DBBYb8C5v19YQ:13137::::::
3) as user1:
$ ssh user2@sshd_servername
$ uid=4002(user2) gid=1(other)
# cat /etc/shadow
...
user2:DBBYb8C5v19YQ:13137::::::1
Putting pam in debug more, we can see:
<omitted log file>
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
Work Around:
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
xxxx@sun.com
However, it should suffice to have:
sshd-none auth required pam_deny.so.1
