thad@cup.portal.com (Thad P Floryan) (01/10/91)
pete@wvus.wciu.edu (Pete Gregory) in <TsNiV1w163w@wvus.wciu.edu> writes:
Could someone please describe for me the differences between what
$HOME/.rhosts and /etc/hosts.equiv do for me, with regards to ftp,
telnet, rlogin, resh access from one system to another?
I was going to say RTFM (Read The Fine Manual), but noticed you DIDN'T ask
about $HOME/.netrc, so maybe you don't have manuals (is this true?)
You should look at hosts.equiv(5), .netrc(5) and .rhosts(5) ... these are the
"man" pages for those files.
If your system is "open" or connected to a network permitting access from
outside your organization, you want to forget you ever even heard of .rhosts
and hosts.equiv since those will open up your system to crackers and other
nasty guys.
If you're on a closed net confined to your organization and you can trust
everyone, then those files, when properly set up, can make life a lot easier
on an internally "open" system.
In summary:
/etc/hosts.equiv is an optional file which, if present, is used by various
facilities to authenticate a request for login coming in from a user
on a remote machine. It basically contains a list of hosts with which
the local hosts has usernames in common. If someone "spoofs" this
feature (i.e. gimmicks their system to have a system name like one in
that file, and (possibly) a similar username, they can be automatically
logged onto your system without a password. Neat, huh? The file
format is:
remotehost [ trustedremoteuser ]
...
$HOME/.rhosts is essentially a "private" version of /etc/hosts.equiv with the
same caveats. Note the file MUST be readable ONLY by the local user
or by root
$HOME/.netrc contains login information for ftp to a remote machine. ftp will
check this file for login information for remote machine(s); if an
entry is not found, then you'll be prompted for username and password
to the remote machine. Again, the file must be readable only by its
owner (ftp CHECKS THIS) because the file format is:
machine machinename login loginname password passwordstring
And there's even a "trick" I haven't seen documented whereby you can "ln"
/bin/remsh to multiple instances of system names on your network to really
make life easy. On my systems what I've done is (abbreviated):
$ ln /bin/remsh /usr/local/bin/thadlabs
$ ln /bin/remsh /usr/local/bin/tlabs1
$ ln /bin/remsh /usr/local/bin/tlabs2
...etc...
and then I can do (for example):
$ tlabs1 ls -l /usr/adm
instead of:
$ remsh tlabs1 ls -l /usr/adm
The programs rlogin, rcp, remsh, rexec and the like will check (actually the
daemons will do this) for the presence of the hosts.equiv or .rhosts and deny
access if they're not present.
Again, if you're concerned about security (and you SHOULD BE), then you
don't want to use any of these "features" or programs.
I strongly suggest you, as SA (presumably System Administrator), get the
lastest posting of "cops" (an 8-part posting) that just appeared in alt.sources
and run a security audit on your system. And be sure you're sitting down when
you read the audit report! :-)
Thad Floryan [ thad@cup.portal.com ]aem@mthvax.cs.miami.edu (a.e.mossberg) (01/10/91)
In <TsNiV1w163w@wvus.wciu.edu> pete@wvus.wciu.edu (Pete Gregory) writes: >Could someone please describe for me the differences between what $HOME/.rhosts >and /etc/hosts.equiv do for me, with regards to ftp, telnet, rlogin, resh >access from one system to another? /etc/hosts.equiv is global, i.e. for all users (except root) It is typically used when you have several machines that have the same users, but for whatever reason you don't use yellow pages. $HOME/.rhosts is for an inidividual user, who may have accounts on several machines not covered by a global /etc/hosts.equiv /.rhosts is for the root only All .rhosts must be unreadable/unwritable by group and others, and owned by the specific user. The .rhosts and hosts.equiv files specify other machines/users and machines (respectively) which can login *from* other systems. .rhosts and hosts.equiv files *only* cover standard UNIX utilities rlogin and rsh. Telnet and ftp (which are TCP/IP clients not specific to any operating system) do not use them. Ftp does have it's own mechanism for specifying logins *to* other systems, but does so in an unsecure way which should not be used (cleartext passwords in a users $HOME/.netrc file). aem -- aem@mthvax.cs.miami.edu ....................................................... The people of Mesa, Arizona, have 5 times as many telephones as the entire country of Honduras. - The Central American Fact Book
dean@truevision.com (Dean Riddlebarger) (01/10/91)
In article <TsNiV1w163w@wvus.wciu.edu> pete@wvus.wciu.edu (Pete Gregory) writes: >Hi - > >Could someone please describe for me the differences between what $HOME/.rhosts >and /etc/hosts.equiv do for me, with regards to ftp, telnet, rlogin, resh >access from one system to another? The short answer: The hosts.equiv file establishes a more loose level of network security when users wish to use rlogin etc. to move amongst various servers on a network. The most obvious manifestation of this is found when using rlogin. If server foo appears in the hosts.equiv file of server bar, and user jdoe has an account on both systems, then he/she will not be prompted for password input when using rlogin from foo to bar. This holds for all users with accounts on both systems, but does not hold true for root. Relaxed security for root with respect to the networking utilities is handled by the /.rhosts file. This scheme allows you to let general users have relaxed access through the hosts.equiv file while keeping tighter control at the root level if you so desire. Of course, using any of these files for relaxed access is potentially dangerous. You should really make sure that your network has minimal or no external access, and you must also be very careful about unattended terminals etc. Of special note is the case in which pcs using DOS-based TCP/IP utilities are connected to a network in which the servers make heavy use of a hosts.equiv scheme. If you assume that jdoe, moving from foo to bar, has already been required to give a password for access to foo, then your security is at least fair. But a good number of people do not equip their DOS boxes with password protection or terminal locking schemes. And if they use, say, the rlogin provided with PC/TCP, and the servers have very liberal hosts.equiv files, then anyone who can turn the DOS machine on and recognize the presence of rlogin can stage a run on their server accounts..... -- <:> Dean Riddlebarger "The bus came by <:> <:> Truevision, Inc. and I got on, <:> <:> [317] 841-0332 That's when it <:> <:> dean@truevision.com uunet!epicb!dean all began." <:>
Dan_Jacobson@ATT.COM (01/12/91)
>>>>> On 10 Jan 91 15:29:06 GMT, aem@mthvax.cs.miami.edu (a.e.mossberg) said:
AEM> All .rhosts must be unreadable/unwritable by group and others [...]
-rw-r--r-- mode works fine for me. Are you saying this for good taste
in security, or will something break otherwise?
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364Kimmo.Suominen@lut.fi (Kimmo Suominen) (01/13/91)
>>>>> On 10 Jan 91 15:29:06 GMT, aem@mthvax.cs.miami.edu (a.e.mossberg) said: AEM> All .rhosts must be unreadable/unwritable by group and others [...] >>>>> On 12 Jan 91 00:25:26 GMT, Dan_Jacobson@ATT.COM said: Dan> -rw-r--r-- mode works fine for me. Are you saying this for good taste Dan> in security, or will something break otherwise? That's the only way it works for me. Additionally, I must have x-permission to other (and I have it for group also) for my home directory. Otherwise I can't access hosts that have my home directory mounted via NFS. This is propably due to root being translated to nobody over NFS-mounts. -- Kim / Internet: Kimmo.Suominen@lut.fi "That's what I think." / Bitnet: KIM@FINFILES
rc@mruxb.UUCP (Richard Casto) (01/14/91)
In article <37825@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > >And there's even a "trick" I haven't seen documented whereby you can "ln" >/bin/remsh to multiple instances of system names on your network to really >make life easy. On my systems what I've done is (abbreviated): This _is_ documented in SunOS 4.1.
ed@lvw6.lvw.loral.com (Ed Allen) (01/15/91)
In article <1053@mruxb.UUCP> rc@mruxb.UUCP (Richard Casto) writes: Path: wdl1.wdl.loral.com!mips!zaphod.mps.ohio-state.edu!wuarchive!uunet!bellcore!porthos!pyuxe!mruxb!rc From: rc@mruxb.UUCP (Richard Casto) In article <37825@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >And there's even a "trick" I haven't seen documented whereby you can "ln" This _is_ documented in SunOS 4.1. Ditto HP-UX. -- Never trust a man who wears white shoes. | Ed Allen Vote Libertarian... Scare the Hell out of 'em. | Loral Command & Contr. Sys. "Sure the game is rigged! But if you don't play | ed@lvw6.lvw.loral.com you can't win!"
thurlow@convex.com (Robert Thurlow) (01/15/91)
In <1991Jan14.204220.21276@mthvax.cs.miami.edu> aem@mthvax.cs.miami.edu (a.e.mossberg) writes: >In <KIMMO.SUOMINEN.91Jan12220436@kannel.lut.fi> Kimmo.Suominen@lut.fi (Kimmo Suominen) writes: >>That's the only way it works for me. Additionally, I must have >>x-permission to other (and I have it for group also) for my home >>directory. Otherwise I can't access hosts that have my home directory >>mounted via NFS. This is propably due to root being translated to >>nobody over NFS-mounts. >So you're saying that root owns your .rhosts? No, no: read what he says. He needs other-x to allow other systems to mount his home directory on his behalf (likely via on/rexd, right Kimmo?). mount(2) has to do an NFS getattr operation after it clears the mount daemon check, and that operatin is done with a credential of 'root'. It seems to me that he'd have no problems if he was in his home directory, but that it would quit working if he tried an 'on' from one of his subdirectories. Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu "The Canadian rock singer, Ronnie Hawkins, has it all figured out. 'Believe in God?' he says, "Man, I believe in God like nobody else. It's the fucking ground crew I don't trust." - "Running Risks", Angela Issajenko