sshd problems:
 

I've got a problem with sshd on one of my systems

I've got two computers, Let's call them C1 and C2

now C2 is connected via ethernet to C1, and C1 is connected to the internet; they both have full network access.

Ever since I've gotten their network to run, C2 refuses to accept passwords from any account using sshd except for root; I'm trying to log into C2 from C1 using sshd.

It gives a "Permission Denied" error and fails every time, regardless of what I set the password to, or what I enter. It works absolutely fine with zero problems on the root account.

I've tried ssh-krb5 and just standard openSSH with no results between either of them.

What's the deal? Is it PAM screwing things up?

PAM is the first thing I would look at. This is what my sshd PAM file looks like:

auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_limits.so
session optional /lib/security/pam_console.so

I just noticed today.


It's the same problem on the console, I can't log in as anyone other than root. I'm not sure what's going on, but it's really irritating.


Also, I rebuilt the kernel a few nights ago, I've been working from the console since then, but it went from kernel version 2.2 something to 2.6.7. Perhaps this could be the problem?

have you checked your /etc/passwd and /etc/group files to see if everything is ok with them?

yep. sure have. no problems, all is normal.

what shell are your users set up to use? is it the same as root? If nothing is wrong with the user accounts, then it must be an authentication problem.

I had problem like this before. It turned out that another sys admin had run a buggy script that changed the file permissions of / to something like drwx------

Just something to check

good point. check the permissions of the users directories and make sure there is x so they can chroot.

nope, the permissions are correct. any other ideas?