0

I have a Rhel 5 VM normally connected to an ldap service and today I discovered that ssh and su were broken. The shell would simply hang while trying either of these commands. I was only able to login as root via console.

ssh was interrupted after the password was accepted (could be seen from /var/log/secure), more specifically at this stage:

debug1: Next authentication method: password
xxxxxxx@xxxxxx's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.

Switching to any local user via su was also impossible although /var/log/secure begged to differ.

As far as ssh is concerned, UseDNS option (/etc/ssh/sshd_config) was commented so I think it's value was 'no'.

And multiple commands (ps, id, su, httpd ..) were generating this error either in /var/log/secure or /var/log/messages

nss_ldap: failed to bind to LDAP server ldap://ldap-bla.bla.bla:###: Can't contact LDAP server 

After sometime I realized that /etc/resolv.conf was misconfigured. I fixed it and the problem solved.

However, I'd appreciate it greatly if somebody could guide me to the understanding of this issue. I can partly see that being unable to reach the ldap server may have affected everything involving remote connections or users but I'd like to know exactly why su to a local user would also be impossible. And how it could've been solved without fixing the ldap. Would removing ldap from nsswitch.conf help?

It was like this:

[root@xxxxxx ~]# grep -i ldap /etc/nsswitch.conf 
passwd:     files sss ldap
shadow:     files sss ldap
group:      files sss ldap
netgroup:   files sss ldap
automount:  files sss ldap
sudoers:  files ldap

Thanks in advance to anybody who'd have the time to reply.

  • 2
    I think that correct question is about unreachable LDAP server instead of resolve.conf. If you setup authentication mechanism to LDAP then obviously anything that require authentication either would fail or succeed depending on reply from LDAP and since it isn't reachable then system chooses logical way to refuse sensitive operations. If you don't need centralized users management (who can access multiple servers with the same credentials) solution then switch to local user authentication via PAM so you will remove network dependency completely. – Alex Aug 27 '18 at 17:12
  • On top of being able to resolve the LDAP server (which seems to be your problem), there are also some DNS records that are used in LDAP, esp. for Active Directory (if you happen to use an Active Directory LDAP server). – dirkt Aug 28 '18 at 5:52

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.