[Bug 1018] Incorrect parsing of hosts.equiv for netgroups

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=1018

           Summary: Incorrect parsing of hosts.equiv for netgroups
           Product: Portable OpenSSH
           Version: -current
          Platform: All
               URL: http://marc.theaimsgroup.com/?l=openssh-unix-
                    dev&m=110909300030444&w=2
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: alek at ast.lmco.com


Per the URL above which was previousely posted to the
open-ssh Email list, but no responses. BTW, I downloaded
the 4.0 source tree and auth-rhosts.c does not appear
to have changed, so I assume the bug still exists.


I just noticed that ssh doesn't parse hosts.equiv the same as rsh.  
I set up an usertest user on targethost, and then su'ed to usertest 
on sourcehost. I put this in targethost's /etc/hosts.equiv
     + -usertest
     + at trusted-hosts    (all hosts are rolled up into this netgroup)
this should disallow usertest from rsh'ing into targethost from all
hosts, but then allow any other users to rsh into targethost without
a password as long as they have a login on targethost. 

What I found was that when I did the rsh from sourcehost, I got 
prompted for a password, but when I did the ssh it let me in without 
a password.  Try a "man hosts.equiv" to see an explanation of what 
I'm doing with the "+ -usertest".

I looked at the openssh3.9p1 source code for auth-rhosts.c and 
around line 100, it looks like there is a bug in that the same
"negated" variable is used for both the host and user checks as
it loops/parses the hosts.equiv file, but seems to me that if one
is denied access because of an explicit rule, you should be disallowed in.

Would be curious if anyone agree with my interpretation of this
behavior and pointer to possible bug in the hosts.equiv parsing?
Thanx,
alek



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.