# ssh password login problem

## jwalcik

i didn't notice this problem until after a recent service outage due to A/C failure in our server room.  since the machine hadn't been rebooted in two months, any one of several different package updates could be at fault.

i have one server running gentoo (the rest are still redhat) that i can no longer log into via ssh when using a password.  all of our user/password information is stored in ldap (for non-root, non-system users), and i've verified that ldap authentication is still working (i can log in as a regular user at the console.  i've also verified that sshd is still working by temporarily enabling root logins and ssh'ing in as root.  i can also log in as a regular user if i use key-based authentication.  however, i'm unable to log in as a regular user using a password.  this is the error i see in the log:

```

Oct  1 09:00:33 dixie useradd: PAM unable to dlopen(/lib/secuirty/pam_ldap.so)

Oct  1 09:00:33 dixie useradd: PAM [dlerror: /lib/secuirty/pam_ldap.so: cannot open shared object file: No such file or directory]

Oct  1 09:00:33 dixie useradd: PAM adding faulty module: /lib/secuirty/pam_ldap.so

```

i've seen a few similar errors posted here that suggested re-emerging pam-login followed by openssh, and i've done so, however the problem persists.  any suggestions?

----------

## sschlueter

I don't know anthing about LDAP, so this answer might be stupid but I'll try anyway:

The missing pam module /lib/secuirty/pam_ldap.so comes from net-libs/pam_ldap and not sys-apps/pam-login.

----------

## jwalcik

the "missing" pam_ldap.so is actually there.  it's the same module pam uses to handle the ldap authentication when someone logs in as a regular user at the console.  that set of messages only appear when someone's trying to log in with a password via ssh.

----------

## Janne Pikkarainen

I wonder why there's a typo in this path:

```
Oct  1 09:00:33 dixie useradd: PAM unable to dlopen(/lib/secuirty/pam_ldap.so)
```

See? "secuirty" instead of "security"? If you did a copypaste from the log, then that's very odd.  :Smile: 

And I would still try re-emerging pam_ldap.

----------

## jwalcik

that was pasted from a log.  i had a typo in /etc/pam.d/system-auth, and i just corrected it (thanks for pointing that out).

however, i'm still not able to log in with a password via ssh.  if i start sshd in debug mode (sshd -d), here's what i get:

```

debug1: sshd version OpenSSH_3.7.1p2

debug1: private host key: #0 type 0 RSA1

debug1: read PEM private key done: type RSA

debug1: private host key: #1 type 1 RSA

debug1: read PEM private key done: type DSA

debug1: private host key: #2 type 2 DSA

socket: Address family not supported by protocol

debug1: Bind to port 22 on 0.0.0.0.

Server listening on 0.0.0.0 port 22.

Generating 768 bit RSA key.

RSA key generation complete.

debug1: Server will not fork when running in debugging mode.

Connection from 128.83.48.195 port 33696

debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p2

debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-1.99-OpenSSH_3.7.1p2

debug1: permanently_set_uid: 22/22

debug1: list_hostkey_types: ssh-rsa,ssh-dss

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received

debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT

debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: KEX done

debug1: userauth-request for user jwalcik service ssh-connection method none

debug1: attempt 0 failures 0

Failed none for jwalcik from 128.83.48.195 port 33696 ssh2

Failed none for jwalcik from 128.83.48.195 port 33696 ssh2

debug1: userauth-request for user jwalcik service ssh-connection method keyboard-interactive

debug1: attempt 1 failures 1

debug1: keyboard-interactive devs

debug1: auth2_challenge: user=jwalcik devs=

debug1: kbdint_alloc: devices 'pam'

debug1: auth2_challenge_start: trying authentication method 'pam'

Failed keyboard-interactive for jwalcik from 128.83.48.195 port 33696 ssh2

debug1: userauth-request for user jwalcik service ssh-connection method passworddebug1: attempt 2 failures 2

Failed password for jwalcik from 128.83.48.195 port 33696 ssh2

Failed password for jwalcik from 128.83.48.195 port 33696 ssh2

debug1: userauth-request for user jwalcik service ssh-connection method passworddebug1: attempt 3 failures 3

Failed password for jwalcik from 128.83.48.195 port 33696 ssh2

Failed password for jwalcik from 128.83.48.195 port 33696 ssh2

debug1: userauth-request for user jwalcik service ssh-connection method passworddebug1: attempt 4 failures 4

Failed password for jwalcik from 128.83.48.195 port 33696 ssh2

Failed password for jwalcik from 128.83.48.195 port 33696 ssh2

Connection closed by 128.83.48.195

debug1: Calling cleanup 0x8075075(0x0)

```

it just keeps telling me i'm using the wrong password, however the same username/password combination works just fine if i try to log in from the console.  

fwiw, i did go ahead and re-emerge pam_ldap, but it didn't appear to change anything.

----------

## Janne Pikkarainen

Ok. So the accounts are only in LDAP and it can't be possible that in console your system is using pam_localuser.so (or something like that) instead of LDAP?

And personally I'm used to have both slapd.conf and ldap.conf under /etc/openldap/ ... sometimes I've been wondering why LDAP isn't working, just to find out many hours later that there's a /etc/ldap.conf file lurking around and the system is using it.

One more possibility: Maybe /etc/pam.d/sshd or other PAM entries have been modified lately?

----------

## jwalcik

nope, the accounts in question exist only in ldap.  if i do add a user to the local /etc/passwd and /etc/shadow, i *can* log in as that user.

my /etc/pam.d/sshd file hasn't been modified recently, and is identical to the same file on another machine (where ssh logins work perfectly).  i even copied the file over and did a diff to check for typos.

i've also re-verified ldap queries to the server are working properly with ldapsearch.

i'm stumped.  all signs point to it being a password error.  however i can turn around and log right in at the console.  i even tried changing the password in ldap.  i can still log right in at the console or via ssh w/ a key, and after i'm logged in, i appear to have the right privileges and can execute commands as root via sudo.  however, no dice sshing in with a password.

are there any other bits of information (logs, config files, etc) that i can post that would be of use?

----------

## Janne Pikkarainen

This sure is getting interesting.

How about OpenLDAP/nss_ldap/pam_ldap versions? Do they match with the working computer? And are they querying the same LDAP server or is the database spread within multiple machines using slurpd or something? 

What if you pump up the slapd's debug level by adding 

```
loglevel 255
```

line to /etc/openldap/slapd.conf and then watch the log?

----------

## jwalcik

the ldap server and all clients are running the 2.0.xx series of openldap.  not all of the clients are running the exact same version however.  the client in question is running the same version as my gentoo desktop, which is working perfectly.

there's only one ldap server that all of the machines are pointed at, it's being replicated but all of the clients are pointed specifically at the one server.

i've tried changing the loglevel in slapd.conf to 255, but it's not very practical right now (it's the middle of the day, and that ldap server is handling authentication for a busy mail server at a large university).  i'll give this a try late tonight when i can temporarily shut down imap/pop3 and get some more relavent information from the log (i turned it on for about 30 seconds and it spat out 7MB of text).

thanks again for the help.  i'll post the ldap debug info late tonight.

----------

## tecknojunky

Verify in the file /etc/ssh/sshd_config and uncomment the line for Use_PAM=yes.

That's how I got it working with ldap

----------

## jwalcik

"UsePAM=yes" did the trick.  many thanks to all!

----------

## Floppe

I can't get it to work with newest openssh 3.7.1 and Use_PAM yes..

But when I emerge openssh-3.6.1_p2 it works!!!

but but...

I don't want to run 3.6.1 becuase of the security bug.

Anyone have any ideas why it won't work with the new package for me?

// Floppe

----------

## axxackall

any news about "Use_PAM=yes" for the latest openssh?

Any other way to force sshd to authenticate through LDAP?

----------

## Krieg

 *axxackall wrote:*   

> any news about "Use_PAM=yes" for the latest openssh?
> 
> Any other way to force sshd to authenticate through LDAP?

 

The person above made a typo, it is "UsePAM=yes".   It made the trick for me.

----------

