[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: openssh and pam_ldap

Hi Jon,

We have a relatively small number of users (~15) and a medium number of hosts that need this access control (~60), so I figured maintaining the user <-> host mappings manually would not be too difficult. But the use of netgroups seems like it would make things even simpler. In addition to some standard netgroups (developers, admins), I can also define a separate netgroup for certain individual hosts, and maintain a list of additional users who are allowed to access that host via the netgroup defined in ldap.

Thanks for the pointer,


Jon Miller wrote:
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,

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 hep caltech edu> 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?


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:

# 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
account     [default=bad success=ok user_unknown=ignore]
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 redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]