000025252 - PAM Agent Solaris 10 sshd allows SecurID challenged user with blank Unix password access without challenge

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000025252
Applies ToACE/Agent for PAM 5.3.4
Solaris 10 SSHD
IssuePAM 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.
CauseSeems 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

Legacy Article IDa33049

Attachments

    Outcomes