LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 01-11-2013, 07:08 AM   #1
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Rep: Reputation: Disabled
ldap client via ssh won't work


Hi,

I'm trying to make my server work with accounts on my ldap but i can't seem to make a connection with the server. So that if i ssh into the server i can use my ldap-account.

I'm running Debian squeeze on the client, the ldap server is still a Debian lenny that has been set up a few years ago by a friend.

This is the /var/log/auth error i got:

Code:
Jan 11 13:45:39 server1 nscd: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/servername not found in Kerberos database)
Jan 11 13:45:39 server1 nscd: nss_ldap: failed to bind to LDAP server ldap://<ip ldap server>: Local error
Jan 11 13:45:39 server1 nscd: nss_ldap: could not search LDAP server - Server is unavailable
When i do nmap -p 389 <ip ldap server> i get this:

PORT STATE SERVICE
389/tcp open ldap

/etc/ssh/sshd_config
Code:
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 4800
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
AllowUsers root user1 guest

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication yes
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes

# GSSAPI options
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
/etc/pam.d/common-account
Code:
account    [default=bad user_unknown=ignore success=ok authinfo_unavail=ignore] pam_ldap.so
account    required     pam_unix.so
/etc/pam.d/common-auth
Code:
auth       required     pam_env.so
auth       sufficient   pam_unix.so try_first_pass likeauth nullok
auth       sufficient   pam_ldap.so use_first_pass
auth       required     pam_deny.so
/etc/pam.d/common-password
Code:
password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow
password   sufficient   pam_ldap.so use_authtok use_first_pass
password   required     pam_deny.so
/etc/pam.d/common-session
Code:
session    required     pam_limits.so
session    required     pam_unix.so
session    optional     pam_ldap.so
session    optional     pam_mkhomedir.so
/etc/ldap/ldap.conf
Code:
uri ldap://<ip ldap server>
base dc=<part1>,dc=<part2>,dc=<part3>

pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
nss_base_passwd cd=<part1>,dc=<part2>,dc=<part3>
nss_base_shadow cd=<part1>,dc=<part2>,dc=<part3>
nss_base_group cd=<part1>,dc=<part2>,dc=<part3>
scope one

timelimit 10
bind_timelimit 10
bind_policy soft
Can somebody see any mistakes or have some idea's to try and fix it

Kind regards
 
Old 01-11-2013, 07:15 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
given there's an error from nss_ldap it's got nothing at all to do with ssh nor pam. You should be aware of what is or is not relevant.... restating your question, you can't retrieve user accounts via ldap.

So it says the server isn't reachable... is it? It's a pretty basic error, suggesting it's just not even possible to telnet to port 389 on that box. Have you tested any smaller component of this solution before you expected everything to work together? to have gotten as far as you say you have, you should've have already proven the ldap server with tools like ldapsearch and getent. Don't run before you can walk.
 
Old 01-11-2013, 07:28 AM   #3
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by acid_kewpie View Post
given there's an error from nss_ldap it's got nothing at all to do with ssh nor pam. You should be aware of what is or is not relevant.... restating your question, you can't retrieve user accounts via ldap.

So it says the server isn't reachable... is it? It's a pretty basic error, suggesting it's just not even possible to telnet to port 389 on that box. Have you tested any smaller component of this solution before you expected everything to work together? to have gotten as far as you say you have, you should've have already proven the ldap server with tools like ldapsearch and getent. Don't run before you can walk.
I'm able to telnet to 389 and even if i do ldapsearch -x it gives a list of all the users in the ldap
 
Old 01-11-2013, 07:35 AM   #4
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
so "getent passwd" presumably doesn't work either? What if you disable nscd?
 
Old 01-11-2013, 07:50 AM   #5
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by acid_kewpie View Post
so "getent passwd" presumably doesn't work either? What if you disable nscd?
getent passwd also works (shows a list) and if i stop the nscd service and try to login with an ldap account it gives the same error message in auth.log
 
Old 01-11-2013, 07:54 AM   #6
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by acid_kewpie View Post
so "getent passwd" presumably doesn't work either? What if you disable nscd?
But not a list with ldap-users, just normal users and stuff
 
Old 01-11-2013, 08:05 AM   #7
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
So you'll be getting the exact same error there, and need to work at that level.

Ahh right... so here's something... you've listed /etc/ldap/ldap.conf but not /etc/ldap.conf. These are actually *TOTALLY* different files (the former is used by ldapsearch and other tools, the latter by nss), so you'll have something in /etc/ldapc.fon which is presumably attempting the wrong authentication method. do you actually want to be using kerberos? I'd generally presume you don't want to...? turn that off in /etc/ldap.conf and try getent passwd again.
 
Old 01-11-2013, 08:13 AM   #8
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by acid_kewpie View Post
So you'll be getting the exact same error there, and need to work at that level.

Ahh right... so here's something... you've listed /etc/ldap/ldap.conf but not /etc/ldap.conf. These are actually *TOTALLY* different files (the former is used by ldapsearch and other tools, the latter by nss), so you'll have something in /etc/ldapc.fon which is presumably attempting the wrong authentication method. do you actually want to be using kerberos? I'd generally presume you don't want to...? turn that off in /etc/ldap.conf and try getent passwd again.
mmm i don't have a /etc/ldap.conf but i do have a /etc/libnss-ldap.conf i'll turn kerberos off in that. It's a file from my first try to connect to the ldap cause the ldap server also has kerberos service running so i thought that maybe my client also needed one.
 
Old 01-11-2013, 08:16 AM   #9
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
Hmm, probably just a change in the built package, it's probably the same file inside. I know that since nslcd replaced nscd in RHEL6, the file it uses, nslcd.conf is unique, with pam using pam_ldap.conf but before this change, all systems I'd used used ldap.conf for both systems, which presumably coudl cause problems or limitations, so a libnss_ldap.conf file makes sense to me.
 
Old 01-11-2013, 08:28 AM   #10
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Reignfire View Post
mmm i don't have a /etc/ldap.conf but i do have a /etc/libnss-ldap.conf i'll turn kerberos off in that. It's a file from my first try to connect to the ldap cause the ldap server also has kerberos service running so i thought that maybe my client also needed one.
Weird sudo suddenly stopped working. Nothing i did last thing i did was read the auth.log which needs sudo to read. It still asks for a password but it says: Sorry, try again. And when i try a new ssh session it's "connection closed by <ip>"
 
Old 01-11-2013, 08:44 AM   #11
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
well sudo will rely on the nss stack aswell, so if nscd is still shutdown, start it. nscd shouldn't be essential though, it's only meant to be a caching layer that's bypassed if it's not available (and was often more trouble than it was worth)
 
Old 01-11-2013, 08:51 AM   #12
Reignfire
Member
 
Registered: Jun 2012
Posts: 56

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by acid_kewpie View Post
well sudo will rely on the nss stack aswell, so if nscd is still shutdown, start it. nscd shouldn't be essential though, it's only meant to be a caching layer that's bypassed if it's not available (and was often more trouble than it was worth)
You have to be sudo to start nscd damn. I can't do a thing if i'm not able to sudo or su to root, should i try recovery mode or a live cd to try and fix something?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Fedora 16 ldapsearch client via ssl won't work dgodbey Fedora 4 06-01-2012 10:17 AM
Setting up SuSE LINUX client to work with IBM Tivoli LDAP server jleak04 Linux - Newbie 1 12-21-2011 05:59 PM
Setting up SuSe Yast LDAP Client to work with IBM Tivoli Directory Server jleak04 Linux - Server 0 12-21-2011 11:56 AM
Passwords fo SSH won't work twaddlac Linux - Networking 16 10-05-2010 12:32 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 08:04 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration