Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What I'm trying to accomplish is if I changed the user's attributes in LDAP to have no shell; for example: /etc/noshell, I do not want the user to ssh successfully. I have changed the attribute of one user:

# check62, people, wh.local
dn: uid=check62,ou=people,dc=wh,dc=local
uid: check62
cn: Johnny Appleseed
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e1NTSEF9dklpL2pQcWtNWDBFSUs1eUVDMUMxL2FjWHdJNGRuUXY=
shadowLastChange: 15140
shadowMax: 99999
shadowWarning: 7
uidNumber: 6002
gidNumber: 6002
homeDirectory: /home/check62
loginShell: /bin/noshell

# check62, group, wh.local
dn: cn=check62,ou=group,dc=wh,dc=local
objectClass: posixGroup
objectClass: top
cn: check62
gidNumber: 6002
userPassword:: e0NSWVBUfXg=

Here is my /etc/pam.d/sshd file

auth       required
auth       include      password-auth
account    required
account    include      password-auth
password   include      password-auth
# close should be the first session rule
session    required close
session    required
# open should only be followed by sessions to be executed in the user        context
session    required open env_params
session    optional force revoke
session    include      password-auth

The user authenticates successfully with /bin/bash. A show stopper. Any help will be greatly appreciated.

Here's my password-auth file

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required
auth        sufficient nullok try_first_pass
auth        requisite uid >= 500 quiet
auth        sufficient use_first_pass
auth        required

account     required broken_shadow
account     sufficient
account     sufficient uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore]
account     sufficient
account     required

password    requisite try_first_pass retry=3 type=
password    sufficient sha512 shadow nullok try_first_pass use_authtok
password    sufficient use_authtok
password    required

session     optional revoke
session     required
session     [success=1 default=ignore] service in crond quiet use_uid
session     required
session     optional
share|improve this question
Wouldn't this be better solved by putting people that are allowed to SSH in a specific group? Named something like role-ssh. – artifex Mar 8 '13 at 18:44
Can you provide the contents of /etc/pam.d/password-auth? – Andrew B Mar 8 '13 at 20:00

Placing files or compat before ldap in /etc/nsswitch.conf is a common practice, but if the person has a local account it will override the LDAP settings.

Try this: getent passwd check62

This will show you the passwd database entry for that user from all sources. If the topmost entry contains /bin/bash instead of /bin/noshell, you will either need to make the shell change in the database your server is prioritizing, or adjust the ordering to present LDAP first. The latter is generally not recommended.

(Disclaimer: If you're using PADL's nss_ldap instead of nss-pam-ldapd, placing ldap first is an even worse idea since the LDAP lookups are not sent to a daemon and every process has to deal with timeouts during NSS lookups. Always make sure you know how your server is going to behave when the LDAP server is unreachable.)

share|improve this answer
I ran get passwd check62 and I got /home/check62:/bin/noshell. The users still can login with a bash shell. Here's my nsswitch.confpasswd: ldap files sss shadow: ldap files sss group: ldap files sss ; – usa ims Mar 8 '13 at 19:19
Maybe because I have nscd running and it's caching the password. First my test script creates the account with a valid shell, it authenticates, it exits, then the script modifies the attributes with /bin/noshell; then it authenticates again successfully with a bash prompt. – usa ims Mar 8 '13 at 19:42
What I said didn't make sense, I think. NSCD shouldn't be the culprit because I'm talking about shells, not passwords. – usa ims Mar 8 '13 at 19:48
Give it a shot, see if it helps. nscd caches data from common NSS services. (chief among which is the passwd table, containing user shells) If that fails, please provide the additional PAM information requested in my other comment. – Andrew B Mar 8 '13 at 20:02
I take that back, maybe nscd is the culprit. I issued the command 'nscd --invalidate=passwd' and the user without the valid shell cannot authenticate successfully. – usa ims Mar 8 '13 at 20:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.