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     pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user        context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so 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      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     sufficient    pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so
  • 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.)

  • 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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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