At my last workplace, we used the host attribute to control access as well. Long story short, we saw the same problem you are describing but not before I left to take a new job at another company. At my current job, I'm actually helping to roll out an LDAP implementation. We are using the pam_access module to control access to machines. What you typically do, with this module, is setup a netgroup in LDAP and then grant the netgroup access in your access.conf file which pam_acess uses. It is a more elegant solution, IMO. Let's say you setup a new database server and need to permit all of your DBAs access. With the host attribute method, you would update every DBA's list of hosts. Very manual procedure which gets old quick. By using netgroups, you simply state that the dba's netgroup is allowed to log into that machine. This method has similar benefits for when you hire a new DBA. -- Jon Miller A bit off topic, but do you delegate permissions via sudo? If so, did you know you can specify a group of people via a netgroup? Combine this style of delegation with your host control and then you can controlling host access as well as sudo permissions by simply adding / removing people from a netgroup. On 9/11/07, Michael Thomas <thomas@xxxxxxxxxxxxxxx> wrote: > I've been fighting with this problem for a couple of days now and > thought it was time to appeal to the experts... > > I'm using RHEL4 with pam_ldap to authenticate users who do not have > local accounts. This works. I'm also using pam_check_host_attr in > ldap.conf to limit who is allowed to log into a host based on their host > attribute in ldap. This also works, mostly. > > When users log in using their ldap password, that is, when ssh prompts > them for their password, the host-based access control provided by > pam_check_host_attr works. Users who don't have the proper ldap host > attribute are denied access. > > But as soon as a user puts a public key in ~/.ssh/authorized_keys, > pam_check_host_attr stops working. Regardless of what is in their ldap > host attribute, openssh lets them in. I want to allow (and encourage) > the use of authorized_keys files for logging into the machines, but I > also want to retain control of which machines they can log into by using > the host attribute in their ldap entry. > > I've tried changing ChallengeResponseAuthentication to 'yes', but then > users are always prompted for their password. I've also tried adding > the 'debug' option to pam_ldap.so and directing all *.debug messages in > syslog to /var/log/debug, but I don't see anything appear from pam_ldap. > > Is it possible to allow ssh key-based authentication, but still prohibit > logins based on the ldap host attribute? > > --Mike > > sshd_config contains: > > Protocol 2 > SyslogFacility AUTHPRIV > ChallengeResponseAuthentication no > GSSAPIAuthentication yes > GSSAPICleanupCredentials yes > UsePAM yes > X11Forwarding yes > Subsystem sftp /usr/libexec/openssh/sftp-server > > /etc/pam.d/system-auth contains: > > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required /lib/security/$ISA/pam_env.so > auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok > auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass > auth required /lib/security/$ISA/pam_deny.so > > account required /lib/security/$ISA/pam_unix.so broken_shadow > account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 > quiet > account [default=bad success=ok user_unknown=ignore] > /lib/security/$ISA/pam_ldap.so > account required /lib/security/$ISA/pam_permit.so > > password requisite /lib/security/$ISA/pam_cracklib.so retry=3 > password sufficient /lib/security/$ISA/pam_unix.so nullok > use_authtok md5 shadow > password sufficient /lib/security/$ISA/pam_ldap.so use_authtok > password required /lib/security/$ISA/pam_deny.so > > session required /lib/security/$ISA/pam_mkhomedir.so > skel=/etc/skel/ umask=0022 > session required /lib/security/$ISA/pam_limits.so > session required /lib/security/$ISA/pam_unix.so > session optional /lib/security/$ISA/pam_ldap.so > > _______________________________________________ > Pam-list mailing list > Pam-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/pam-list > _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
