Possible bug in openssh parsing of hosts.equiv for netgroups?
Alek O. Komarnitsky (N-CSC)
alek at ast.lmco.com
Wed Feb 23 04:09:52 EST 2005
Open-SSH'ers,
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
More information about the openssh-unix-dev
mailing list