home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / kerberos / 673 < prev    next >
Encoding:
Text File  |  1992-09-07  |  2.6 KB  |  55 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!CYGNUS.COM!eichin
  3. From: eichin@CYGNUS.COM ("Mark W. Eichin")
  4. Subject: Re: my previous question refined
  5. Message-ID: <9209050013.AA28302@tweedledumber.cygnus.com>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Sat, 5 Sep 1992 00:13:02 GMT
  9. Lines: 44
  10.  
  11. Mr. Nesset makes several comments...
  12. > the remote machine. To protect it, you probably want to logon originally
  13. > by executing "rlogin -x". Of course, this means either knowing ahead of
  14. > time you want to change to root, or (more likely) always executing "rlogin -x".
  15.     I do work cross-country (via AlterNET and NEARnet); the 56Kbps
  16. link at the other end is far more of a bottleneck than DES encryption
  17. will ever be. I always use encrypted rlogin. 
  18.     Note that the 91.03.25 version of telnet does support toggling
  19. encryption on and off, inbound and outbound, if you do notice the
  20. performance. 
  21.  
  22. > Jon Rochlis suggests either using ksu or "rlogin -l root". The latter option
  23. > doesn't work for Telnet.
  24.     Actually, when the aforementioned telnet is invoked as rlogin,
  25. it *does* work. (It seems not to work for root, but there is no
  26. problem switching to other users based on the .klogin file; failing as
  27. root in particular appears to be simply a bug.)
  28.  
  29. > access tickets) and then logon to the remote machine. I'm not sure, but
  30. > I think this means that a user with root privilege has those privileges
  31. > on all machines.
  32.     The only machines that a user with a root instance has root
  33. access to (via rlogin or ksu) are those with their root instance
  34. listed in the /.klogin file. This could easily be no machines at all;
  35. root access has nothing to with the name of the instance, all that
  36. matters is that the name of the principal given is on the access
  37. control list.
  38.  
  39. > Barry Jaspan points out that support of ksu could provide a security hole
  40. > if the machine doesn't have a rcmd.<hostname> srvtab. That's another concern,
  41.     If the machine is "tightly kerberized" as you describe, then
  42. without such a srvtab, you won't be able to get in at all, other than
  43. from a directly wired terminal, so ksu won't be a threat. It is still
  44. important to be careful about making ksu available on "client only"
  45. machines that don't have such a srvtab.
  46.  
  47. > do root work, you logoff the remote machine, su to root (which gets root
  48. > access tickets) and then logon to the remote machine. I'm not sure, but
  49.     I don't think Jeff implied that it was necessary to log off;
  50. most of us use window systems of some sort, so popping up an
  51. additional connection isn't a hassle.
  52.                     _Mark_ <eichin@cygnus.com>
  53.                     Cygnus Support --
  54.                     "Cygnus Network Security"
  55.