# ssh password login fails w/ UsePAM and NIS

## rstanchak

I can't ssh into my box unless I'm root OR if I'm using public key authentication.  Ssh asks for my password 3 times, then I get a

On the server's log, I get

```

/var/log/sshd/current:

Feb 16 21:40:50 [sshd] error: PAM: Authentication failure for rstancha from cc3-24.217.192.143.charter-stl.com

/var/log/pwdfail/current:

Feb 13 14:35:46 [sshd(pam_unix)] authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=cc3-24.217.192.143.charter-stl.com  user=rstancha

Feb 13 14:35:48 [sshd] error: PAM: Authentication failure for rstancha from cc3-24.217.192.143.charter-stl.com

```

My /etc/ssh/sshd_config specifies:

```

PasswordAuthentication no

UsePAM yes

```

These settings are both opposite from an older sshd config file on another system, and I suspect that changing them back to 'yes' and 'no' respectively will fix this problem.  However, I imagine the Gentoo maintainers changed them to the current settings for a good reason.  Given this -- to get password ssh login to work again, what SHOULD I fix?

My /etc/pam.d/sshd

```

auth       required     pam_stack.so service=system-auth

auth       required     pam_shells.so

auth       required     pam_nologin.so

account    required     pam_stack.so service=system-auth

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth

```

and /etc/pam.d/system-auth

```

#%PAM-1.0

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok

auth       required     /lib/security/pam_deny.so

account    required     /lib/security/pam_unix.so

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

```

Given the error message in the log above it looks like the pam_unix module is the guilty party.  Any ideas?

----------

## cselkirk

I can't reproduce this, and comparing the above pam.d/{sshd,system_auth} and the entries in sshd_config on the machine in question they are practically identical (other than additional entries for pam_ldap in system_auth, but these we can safely forget about i think as the user in question is not authenticated via ldap). So, I'm fairly sure pam_unix is not at issue.

Your client supports ssh2 I take it? (ssh2 is inforced in the sshd_config).

I'm not sure what else to suggest, perhaps check the account information for the user your logging in as, change  (or at least validate) the users password.

----------

## rstanchak

This is puzzling.  I can log in on the console just fine, and as I mentioned, public key authentication works.  I should mention that I'm authenticating against a NIS server not a local passwd file.  I should probably add a local user and see if that makes a difference.  Ahah! It does...I can log in just fine with a local user.  Any more ideas?

----------

## cselkirk

 *rstanchak wrote:*   

> I should mention that I'm authenticating against a NIS server not a local passwd file.

 

In that case I think your system-auth should have something like the following:

```
password    sufficient    /lib/security/pam_unix.so nullok md5 use_authtok nis
```

It might be a good idea to post your nsswitch.conf also.

HTH

----------

## rstanchak

I added the nis flag to system-auth to no effect

Here is my /etc/nsswitch.conf

```

# CFENGINE STATIC FILE

passwd:     compat

shadow:     compat

group:      compat

passwd_compat: nis files

group_compat: nis files

shadow_compat: nis files

hosts:      files dns nis nisplus

bootparams: nisplus [NOTFOUND=return] files

ethers:     files

netmasks:   files

networks:   files

protocols:  files

rpc:        files

services:   files

netgroup:   nis

publickey:  nisplus

automount:  files nisplus

aliases:    files nisplus

```

Thanks for the help thus far!

----------

## cselkirk

 *rstanchak wrote:*   

> 
> 
> ```
> passwd_compat: nis files
> 
> ...

 

I would say the search order should be reversed to "files nis" (though I should admit that I'm fairly unfamilair with NIS). This doesn't really explane why your logins are failing as the authentication process should fallover to the second, but I would say it's best to first start with files as then you have at least the possibility to login if your authentication method (LDAP, NIS) is unavilable.

Unrelated question, do you use cfengine to maintain your configuration files?

HTH

----------

## rstanchak

Nope, no CFENGINE -- I copied the nsswitch.conf file from a redhat system which apparently did use it. 

I managed to solve my problem by changing my /etc/pam.d/sshd to the following:

```

auth       required     pam_unix_auth.so

auth       required     pam_nologin.so

account    required     pam_unix_acct.so

password   required     pam_cracklib.so

password   required     pam_unix_passwd.so use_authtok

session    required     pam_unix_session.so

```

I don't really understand why this fixed it, or if this is even a good configuration.  Any insight?

----------

## cselkirk

I think you have simply bypassed system-auth as as far as I can remember all the login/ssh etc are all handled by pam_stack.so and passed to system-auth.

I'm fairly unknowledgeable WRT pam. I have had a rather long, loud and at points humours discussion with a friend here who had been setting up a (windows client) network whos images were server via bootp and authentication was done via pam, he was quite adament in his dislike for pam stating that it's a complete hodge podge (with features in one component that are completely missing in others). Additionally he claimed that after so many hours trying to get a documented feature working he found notes in the code itself which, as I remember, stated that the "feature" simply didn't work (forgive my memory, this was about four or five months back).

Anyhow, it works .. what more can you ask for .. other than to know why, exactly .. heh

----------

