Dan_Jacobson@ATT.COM (10/24/90)
I heard that a line like
durian.rambutan.edu asamjawa
is more secure than a line like
durian.rambutan.edu
in my $HOME/.rhosts file ...supposedly protecting against rlogin -l
attacks. But I feel protected already and see no added effect. (And
yes, both don't thwart someone with the root passwd on another
machine coming into durian.rambutan.edu impersonating me). (I'm on
SunOS 4.0.3 etc.).
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364Dan_Jacobson@ATT.COM (10/28/90)
I've got 3 responses [Ed K., Jeff L., Mike M.]. My experience: bob@beep$ cat ~/.rhosts peep pam@peep$ rlogin -l bob beep Password: <--see, it asked pam for a password, so bob doesn't need to say "peep bob" in his .rhosts file to keep pam out, as some folks suggested. Saying just "peep" there worked fine. [SunOS 4.0.3, nothing in /etc/hosts.equiv or /.rhosts. pam and bob don't know root passwd. "man rhosts" doesn't seem to contradict the above. "man rhosts" says the 2nd field is optional, in contrast to "man rlogin".] Apparently the only use is if bob is called bob1 on peep, and bob on peep is somebody else. Then this would make sense, bob@beep$ cat ~/.rhosts peep bob1 ...both keeping bob@peep out of bob@beep's account, and letting bob1@peep login into bob@beep without a password. All well and good. But I see no case where NAME1@host1$ cat ~/.rhosts host2 NAME1 increases security, or changes anything. [Same NAME1, both in the user's name (represented by their prompt here), and in their 2nd ~/.rhosts field] [I'm talking about regular users throughout this article, not root, etc.] -- Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364
Dan_Jacobson@ATT.COM (10/29/90)
>>>>> On Sun, 28 Oct 90 21:54:13 +0100, birger@eik.ii.uib.no said:
birger> I'm unable to post, so i mail you an answer to your question.
birger> If you know that your user-number (uid) is the same on all
birger> hosts (e.g. use of YP/NIS or other way of sharing passwd file)
birger> then you don't need your username in the file.
birger> if user foo is user number 200 on host alpha, 300 on host
birger> beta, a .rhosts file on beta saying just "alpha" won't be good
birger> enough for foo to rlogin, even if he uses "rlogin beta -l
birger> foo".
[hmm, mine seems to map on usernames, not id's]
birger> If user bar on alpha is user 200, then bar would be able to
birger> say "rlogin beta" and get logged in as foo.
[you mean 300[?], Mine still maps on usernames.]
birger> The morale is: If the passwd list is distributed (e.g. you
birger> don't need -l option for rlogin) then just hostname is secure.
birger> --
birger> ____ ____ ____ ____ ____ birger@ii.uib.no
birger> / / / / / / / / / /
birger> / / / / / / / / / / Birger A. Wathne
birger> /--- / /--- / __ /--- /--- Blekenberg 14
birger> / / / / / / / / / / N-5037 SOLHEIMSVIK
birger> /____/ / / / /____/ /____ / / tlf: +47-5-20 00 62
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364chris@mimsy.umd.edu (Chris Torek) (10/29/90)
There seems to be a deep misunderstanding here as to how `.rhosts' files
work.
When you use the `rsh' and `rlogin' commands, the machine receiving the
rsh or rlogin request is handed two pieces of information: the Internet
host number of the requesting machine, and the user name of the person
who ran the request. It is up to the requesting machine to provide the
correct user name; it is up to the receiving machine to derive the
correct host name given the Internet host number. There are ways to
fool both, though with sources and ingenuity the scheme can be made
reasonably secure. (Someone can still come in, replace a trusted
machine with a PC or Macintosh, and pretend to be that machine, for
instance, so `absolute security' is impossible. Even if you post armed
guards, they can be bribed or otherwise put out of action.)
For instance, if you are logged on to `foovax.outer-podunk.edu' as
`susan' and enter the command `rsh foosun echo hello', foovax makes a
connection to foosun (presumably also in `outer-podunk.edu') and says,
`hi, susan is asking susan to run the command "echo hello"'. Foosun
can look up the Internet number on the request and convert this back to
`foovax.outer-podunk.edu'. (If it uses Internet name service, and
the server(s) is/are down, it may be stuck with just the numbers.)
Now two things happen:
A. foosun reads /etc/hosts.equiv. If `foovax.outer-podunk.edu'
appears, it says `aha, foovax is trusted, and susan on foovax is
the same person as susan here on foosun'.
B. foosun reads ~susan/.rhosts. If `foovax.outer-podunk.edu' appears,
either it is on a line by itself, or it is followed by a user name.
If a user name appears, foosun will believe that foovax is trusted,
but rather than assuming that susan on foovax is the same as the
susan on foosun, it will instead assume that whatever string appears,
*that* is the person who, on foovax, is the same as susan on foosun.
If no user name appears, foosun assumes this means susan on foovax.
Now, if you type `rsh foosun -l bob echo hello', foovax connects to
foosun and says, `hi, susan is asking bob to run the command "echo
hello"'. This time foosun reads ~bob/.rhosts (along with
/etc/hosts.equiv, rather pointlessly since susan is asking bob and
therefore nothing in hosts.equiv counts anyway---it is possible, but
stupid, to put user names in hosts.equiv since the same code is used,
but never mind that). If ~bob/.rhosts says `foovax.outer-podunk.edu'
(without also naming susan), foosun will refuse to run the command, but
if that file says `foovax.outer-podunk.edu susan', foosun will run it.
In other words, the only thing changed by adding a user name is that
the local machine (the one reading the .rhosts file) will allow commands
when the remote machine lists the named user as the originator, rather
than the user asked to run the command. This only happens when you use
the `-l' option on rsh or rlogin.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain: chris@cs.umd.edu Path: uunet!mimsy!chrisper@erix.ericsson.se (Per Hedeland) (10/31/90)
In article <27236@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > B. foosun reads ~susan/.rhosts. ... > If no user name appears, foosun assumes this means susan on foovax. I.e., there is no security advantage to adding 'susan' to the foovax line in ~susan/.rhosts, which I believe is what the original poster thought too. There is however one case where the presence of a username can make a difference, namely if two or more users (=usernames) share a home directory - e.g. there is another login 'jane' with the same home directory as susan, and consequently ~jane/.rhosts is really the same file as ~susan/.rhosts. In this case, if someone tries to login from foovax as jane, the foovax line without a username will be interpreted as jane on foovax, whereas if the line had included the username 'susan', it would (of course) still have been interpreted as susan on foovax. I don't think this has any bearing on security, though. > This time foosun reads ~bob/.rhosts (along with >/etc/hosts.equiv, rather pointlessly since susan is asking bob and >therefore nothing in hosts.equiv counts anyway---it is possible, but >stupid, to put user names in hosts.equiv since the same code is used, >but never mind that). Yes, it is utterly stupid indeed, since if the username susan is listed on the foovax line in /etc/hosts.equiv, it is taken to mean that susan on foovax is equivalent to *any and all* users on foosun (except those that have userid 0), i.e. susan on foovax can do rlogin foosun -l <user> without password, for *any* <user> that isn't superuser - this may have some bearing on security... - especially since some security advice calls for the abolishment of .rhosts files, and thus an administrator might perhaps be tempted to solve the "different username" problem using /etc/hosts.equiv... --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per
imp@marvin.Solbourne.COM (Warner Losh) (10/31/90)
In article <1990Oct30.194948.2439@eua.ericsson.se> per@erix.ericsson.se (Per Hedeland) writes: >There is however one case where the presence of a username can make a >difference, namely if two or more users (=usernames) share a home directory Another reason to add them is if you ever change accounts, or use the same .rhost file for different machines/accounts (I had five accounts at school that all shared the same .rhost file (copies)). Adding the name reinforces that I want "warner at hydrovax" to use this account, rather than "whatever I am now at hydrovax". Warner -- Warner Losh imp@Solbourne.COM How does someone declare moral bankruptcy?
amb@apple-gunkies.ai.mit.edu (Andrew M. Boardman) (11/01/90)
A point most have been missing: what if the .rhosts file is shared via NFS among diggerent machines, on which you have different usernames? Silly situation, but it's happened before... /a
gckaplan@sag4.ssl.berkeley.edu (George C. Kaplan) (12/01/90)
In article <1990Oct30.194948.2439@eua.ericsson.se> per@erix.ericsson.se (Per Hedeland) writes: >There is however one case where the presence of a username can make a >difference, namely if two or more users (=usernames) share a home directory Usernames in ~/.rhosts files can also be useful to control access to shared accounts. At our site there are several special-purpose group accounts that can each be used by several people. (Don't ask why). Rather than set these up as normal accounts, with passwords that gradually become widely known, we're now setting them up with no acceptable password (ie. a '*' in the passwd field), so you can't just login. Instead, the authorised users are in the ~/.rhosts file; they login as themselves first, then rlogin to the group account. George C. Kaplan Internet: gckaplan@ssl.berkeley.edu Center for EUV Astrophysics gckaplan%ssl@jade.berkeley.edu University of California UUCP: ...!ucbvax!sunspot.ssl!gckaplan Berkeley, CA 94720 (415) 643-5651