shark@csustan.UUCP (Chris Rhodes) (07/03/88)
Okay, before my rather naive question, a qualifier: I've only been able to use rlogin on a system where 'localhost' was the only choice, or where I have had no accounts on any of the adjacent hosts... Anyway, how does rlogin get away with logging you in on another system without going through the password prompting? What exactly is the program run on the remote host - login, or a replacement? Am I correct in guessing that the remote host reads your .rhosts file? And (this really is a theoretical question as I have no desire to do this) wouldn't getting into your friend "larry"'s account on an adjacent host without having to supply the password be as easy as asking the administrator of your system to change your login name to "larry" and then rlogin'ing? Thanks. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = D. Chris Rhodes uucp: ...lll-crg!csuh!shark or lll-crg!csustan!shark = = Tiburon Systems Unix and MS-DOS Applications, for now..... = = (Ubiquitous Disclaimer and Humorous Saying Goes Here.) = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
chris@mimsy.UUCP (Chris Torek) (07/04/88)
In article <1151@csustan.UUCP> shark@csustan.UUCP (Chris Rhodes) writes: >... how does rlogin get away with logging you in on another system >without going through the password prompting? What exactly is the >program run on the remote host - login, or a replacement? login (with the -r option). >Am I correct in guessing that the remote host reads your .rhosts file? Yes. It also looks in /etc/hosts.equiv (except for root). >And (... theoretical question ...) wouldn't getting [into another] account >on an adjacent host without having to supply the password be as easy as >asking the administrator of your system to change your login name ...? If the remote machine's hosts.equiv lists your system or the remote user's .rhosts file lists your system and the (changed) login name, yes. The .rhosts mechanism essentially involves trust: You must trust any hosts you list in hosts.equiv not to give any of your login names to anyone other than those to whom *you* gave those login names. (Typically, this means that *you* also give out the login names on the hosts listed in /etc/hosts.equiv.) You must also trust each of those hosts not to violate the 4BSD-unix-network-`security' protocol (essentially, never sending packets with TCP ports < 1024 from other than privileged programs). Likewise, were I to add Monsoon U's `mongoose' to my .rhosts, with a different login name: mongoose.monsoon.edu ctorek I would be trusting mongoose's administrator not to let anyone but me use the `ctorek' name, and not to let anyone there spoof a TCP packet from a `secure' port. Furthermore, I would also be trusting all the networks between here and Monsoon U not to allow anyone else to spoof a TCP packet from Monsoon U. That takes quite a bit of trust! Well, there is always Kerberos from MIT.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris