Have you tried looking at the auth.log? Maybe that will give you some hint. I've found that pam is very good about outputting stuff to the auth.log. I was able to debug one problem from looking at the auth.log and seeing that pam couldn't contact the ldap server because the permissions on my libnss-ldap.conf file accidentally had the wrong mode.
jamie. On Mon, Jun 27, 2005 at 10:36:34AM -0700, Matt Dunford wrote: > On Sun, Jun 26, 2005 at 09:42:55AM -0400, [EMAIL PROTECTED] wrote: > > Hello. I just yesterday finished setting up a lab with ldap and nfs for a > > group > > of amd64 machines. It seems to be working smoothly at the moment. > > Cool, I'm glad to see that I'm the only one with problems. This way > at least we know the problem is me and not the debian port. > > > > There's definately some duplicates (tty, nobody, etc). But I'm not > > > sure what will happen if I take those out, the ldap server being in > > > production and all.. > > > > Is this wise? I ask, because I honestly don't know. I would assume that > > this > > is a bad idea. I would think there should be no possible dupblicate user > > mappings. Something is bound to get confused. In general I also think that > > there is probably no reason whatsoever to share system user account > > information > > anyway. Each machine should handle system accounts locally. System group > > information seems a bit trickier, though, since system group membership > > information would not be shared. > > I don't believe it's a bad idea. Take this entry in > /etc/nsswitch.conf as an example: > > hosts: files dns nis > > When looking up a hostname, the system should consult /etc/hosts > first. If it doesn't exist there, then it consults dns. If it's in > dns, it returns the ip of the hostname. Even if the same entry is in > nis, it doesn't matter, since it doesn't query nis. It's already got > it's info from dns. > > At least that's how I thought the nsswitch.conf files worked: on a > first come, first serve basis. > > So in a similar way when looking for system accounts (like root), it > will query files first. And if it doesn't find an entry, then it > queries ldap. > > Also browsing through the ldap logs, I don't see any queries for > system accounts go by. > > > I have been using getent to see what name service is reporting as all > > available > > users and groups. > > Things like `getent passwd username` and `id username` work correctly. > automounting too. They all draw their info from the ldap server. I > have the ldap log open as I test this and can see their queries go by. > > Ssh (and the other login mechanisms) also communicate correctly, but > then just hang like I described before. > > > I use the configuration recommended in the libpam-ldap README.Debian that > > looks > > like this: > > > > auth [success=1 default=ignore] pam_unix.so > > auth required pam_ldap.so use_first_pass > > auth required pam_permit.so > > > > for essentially all of my common-* pam config files (the above is my > > common-auth). This configuration seems to work for me. > > I've given that one a try too. I'm at my wit's end. It must be > something small as ldap works on everything but the amd64s. > > > I wish I could be of more help. How do you know where it is that sshd hangs > > during the connection attempt? > > I googled around and found a few examples of how ssh developers debug > their code in gdb. So I applied the same method and that's how I got > the backtrace. > > -- > Sincerely, > Matt Dunford > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
