Trouble with nss|pam|openldap

[Jason Lixfeld]

I'm using openssh-portable and the latest versions of openldap,  
pam_ldap and nss_ldap.  It appears as though the system is using  
ldap, but I can't seem to ssh in as an LDAP user.  I get a permission  
denied.  ssh debugs don't show anything useful and openldap debugs  
don't seem to show any activity when I enter the password, but it  
does show activity when I initially perform the ssh connection.  That  
seems strange to me because I don't see a query in the debugs for the  
user password, even after I enter it in.  I tried putting the  
pam_ldap lib in the password section of the /etc/pam.d/sshd file, but  
that was useless too.  Local users can ssh in fine.

I searched through the bugs and it seems there is a bug in nss_ldap  
with regards to getpwuid, but that seems to be more if an indicator  
about why finger doesn't work, not why ssh does't work

(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/91806)

Anyone see anything that strikes them as why this may not work?

$ pkg_info
nss_ldap-1.249      RFC 2307 NSS module
openldap-client-2.3.23 Open source LDAP client implementation
openldap-server-2.3.23 Open source LDAP server implementation
pam_ldap-1.8.0      A pam module for authenticating with LDAP
php5-ldap-5.1.4     The ldap shared extension for php
phpldapadmin-1.0.1,1 A set of PHP-scripts to administer LDAP over the  
web
openssh-portable-4.3.p2_1,1 The portable version of OpenBSD's OpenSSH

$ uname -srm
FreeBSD 6.1-RELEASE amd64

# /usr/local/etc/nss_ldap|ldap.conf:

base dc=example,dc=com
uri ldap://127.0.0.1/
binddn cn=Manager,dc=example,dc=com
bindpw sillypassword
bind_timelimit 10
bind_policy soft
nss_connect_policy oneshot
pam_filter objectclass=posixaccount
pam_login_attribute uid
pam_password ssha
nss_base_passwd         ou=people,dc=example,dc=com?one
nss_base_shadow         ou=people,dc=example,dc=com?one
nss_base_group          ou=groups,dc=example,dc=com?one

# id testuser seems to work, finger doesn't.  Curious.  Anyway, it  
still appears as though at least some portions of the system are  
using LDAP, which is good.
$ id testuser
uid=2000(testuser) gid=2000(testuser) groups=2000(testuser)
$ finger testuser
finger: testuser: no such user
$

# /etc/pam.d/sshd

auth            required        pam_nologin.so          no_warn
auth            sufficient      pam_opie.so             no_warn  
no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn  
allow_local
auth            sufficient      /usr/local/lib/pam_ldap.so      debug
auth            required        pam_unix.so             no_warn  
try_first_pass
account         required        pam_login_access.so
account         required        pam_unix.so
session         required        /usr/local/lib/pam_mkhomedir.so
session         required        pam_permit.so
password        required        pam_unix.so             no_warn  
try_first_pass

# user/group data:

dn: cn=Test User,ou=people,dc=example,dc=com
cn: Test User
sn: Dummy
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: testuser
uidNumber: 2000
gidNumber: 2000
gecos: TestUser
loginShell: /bin/csh
userPassword:: e01ENX1YWnhveHNVTzA5QXFMODlVOWptVHRnPT0=
homeDirectory: /home/testuser

dn: cn=testuser,ou=groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
gidNumber: 2000
memberUid: testuser
cn: testuser

# ssh attempt:

$ ssh testuser at 192.168.100.200
testuser at 192.168.100.200's password:
Permission denied, please try again.