From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Galeon/1.3.18 Description of problem: I've got two machines (a and b). Machine a is running rhel3 ws with no updates, machine b is running rhel3 as U3. Machine a and b have identical /etc/sysconfig/authconfig options: USEDB=no USEHESIOD=no USELDAP=no USENIS=yes USEKERBEROS=no USELDAPAUTH=no USEMD5=no USESHADOW=no USESMBAUTH=no both machines mount home directories from a nfs server. on both machines my /etc/passwd entry (jon, id 1001) is listed in nis and not locally. when i ssh as myself to machine a, i'm automatically logged in (i have dsa keys set up). when i ssh as myself to machine b , i'm asked for a password, and (if i bother to enter one) i get rejected. if i ssh into machine b as root (for instance, could be any user listed in the local passwd file), not only can i log in, but i can finger myself and see correct information. also, id and getent both work locally as well. nis is working in every other circumstance i can devise (ypcat works), but not when i'm trying to ssh in. also, no other redhat-based linux here has this issue. redhat 7.2/7.3/8.0/9 and fedora core 1/2/3 all work fine. here are the specifics for each machine: machine a (nis works here): [jon@a jon]$ rpm -q pam ypbind yp-tools authconfig glibc pam-0.75-51 ypbind-1.12-1 yp-tools-2.8-1 authconfig-4.3.7-1 glibc-2.3.2-95.3 machine b (nis doesn't work here): [jon@b jon]$ rpm -q pam ypbind yp-tools authconfig glibc pam-0.75-58 ypbind-1.12-5 yp-tools-2.8-1 authconfig-4.3.7-1 glibc-2.3.2-95.27 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. ssh into rhel3 machine with at least U2 or U3 Actual Results: get rejected Expected Results: i should have been logged in. Additional info:
Could it be the bug 138937? Also could you try to look into the syslog if there is something suspicious?
i don't think it's bug 138937, since none of these machines have had glibc updated on them (they were all installed from the U3 cd, and haven't had an upgraded glibc). here's what's in syslog when i try to ssh in: [root@engweb log]# tail /var/log/messages Nov 30 12:21:32 localhost portmap: portmap shutdown succeeded Nov 30 12:21:33 localhost portmap: portmap startup succeeded Nov 30 12:21:34 localhost ypbind: ypbind shutdown succeeded Nov 30 12:21:34 localhost ypbind: ypbind startup succeeded Nov 30 12:21:34 localhost ypbind: bound to NIS server a.vmware.com Nov 30 12:21:50 localhost sshd(pam_unix)[8398]: check pass; user unknown Nov 30 12:21:50 localhost sshd(pam_unix)[8398]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=remote.vmware.com Nov 30 12:22:10 localhost sshd(pam_unix)[8398]: check pass; user unknown Nov 30 12:22:15 localhost sshd(pam_unix)[8398]: check pass; user unknown Nov 30 12:22:17 localhost sshd(pam_unix)[8398]: 2 more authentication failures; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=remote.vmware.com
What gives you 'getent passwd <username>' ?
> What gives you 'getent passwd <username>' ? [root@engweb root]# getent passwd jon jon:apasswordhash:1001:201:Jonathan Schatz:/exit14/home/jon:/bin/bash this is correct (and from nis).
Hmm, strange there seems to be no change in pam_unix between RHEL3 and RHEL3 U3. So this means the problem must be somewhere else.
Do you have privilege separation enabled in SSH? What results (with syslog) you get if you try to login as the same user on console? Also could you set some simple password for this user and post complete getent passwd <username> output?
ok, i'm not sure what was going on with nis here. i went to the console of the original machine i found this problem on, and could login fine. i then tried to ssh to the machine, and got the same error from above. i changed the sshd_config file to enable privsep, and restarted sshd. i then could log in. thinking i had solved the problem, i ssh'd into the other machines i had issues on to change their sshd configs, and found that i had no problems logging in at all (without changing their sshd config or restarting sshd). so i'm resolving this bug and assuming that something was out of whack on our nis servers. if i can somehow reproduce this issue i'll reopen this bug.