Date: Wed, 24 Mar 1999 23:46:09 -0800 From: Mike Thompson <miket@dnai.com> To: Gary Gaskell <gaskell@isrc.qut.edu.au>, Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos vs SSH Message-ID: <4.1.19990324234311.00a0eba0@mail.dnai.com> In-Reply-To: <Pine.GSO.4.10.9903251445280.17330-100000@primrose.isrc.qut .edu.au> References: <199903250426.UAA68023@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the response. I wanted both central admin of authentication and strong crypto, but I didn't know that ssh could be easily configured to work with Kerberos. It seems that by combining the two that I get the best of both worlds. The general concensus seems to be that rsh and like tools can be easily hacked, kerberos or no kerberos. Thanks again, Mike At 02:49 PM 3/25/99 +1000, Gary Gaskell wrote: > >Perhaps we (myself) am confused. I thought you wanted a rsh like tool, >that used strong crypto (liek ssh does), but has a central control point, >rather than ssh's peer-to-peer architecture. > >The rsh I mentioned in the MIT kerberos distribution is is kerberised. >the command is krsh and the server is krshd which can be started from >inetd. > >Personally I would have agreed back in 1994 that the MIT beta distribution >of Kerberos was a little uninituitive to setup, but I think it's pretty >good now. I know I had a web page back in those days detailing each step. >Others have now gone further. > >Best wishes with your project. > >Gary > >On Wed, 24 Mar 1999, Matthew Dillon wrote: > >> :I was using rsh/rlogin with a kerberos server for something similar 5 >> :years ago (kerberos v5) and it was all free, save the time of compilation >> :and configuration. >> : >> :What's the problem? the rtools are part of the MIT distribution. >> : >> :Gary >> : >> :On Wed, 24 Mar 1999, Mike Thompson wrote: >> : >> :> We are configuring a series of web servers running FreeBSD 2.2.8 >> :> for a new Internet service. To implement our service we need >> :> to provide a mechanism for secure communication between the >> :> servers using an rsh-like facility. >> :> >> :> One method of doing this would be to run SSH on each server for >> :> encrypted/authenticated communication. However, the downsides >> :> of this are that there wouldn't be a central administration >> :> facility for managing authentication information (unless we >> :> create one), ssh has a relatively high CPU overhead to encrypt >> :> all communications and we would like to avoid paying the substantial >> :> license fees for SSH across a large number of servers. >> :> >> :> An alternative would be to run a rsh in combination with a >> :> Kerberos server to centrally administer authentication >> :> information between each server. Communication between the >> :> servers would take place behind a router to prevent >> :> interception of the unencoded packets. We would also use >> :> IPFW to restrict communication with rsh as further protection >> :... >> >> SSh can be configured to use kerberos V fairly easily. I set the >> following in my /etc/make.conf.local: >> >> MAKE_KERBEROS5= YES >> KRB5_HOME= /usr/krb5 >> >> And then I build the krb5 port and the ssh port. >> >> Of course, in order to use kerberos you need to setup a kerberos >> server, and kerberos is extremely user unfriendly when it comes >> to figuring out how it works. But if you can get past that point >> you can get ssh working w/ kerberos. >> >> This is what BEST.COM does. We also disallow passworded root logins >> except on the console ( even w/ ssh ), and use the kerberos 'ksu' >command >> to control access to root. This allows us to configure a crypted root >> password in the password file good for logging into the console, but >> useless if stolen and decrypted. All other accounts have '*' for their >> password ( i.e. ssh+kerberos logins only). Use of ssh authorized_keys >> files are also discouraged, though we do use them for direct root-root >> cron'd administrative functions from two 'secured' machines. >> >> rsh, rlogin, telnet, exec, and other administrative services are disabled >> entirely on administrative machines. sshd is the only way to get in >apart >> from finding a hole in the servers running that implement the function >> and purpose of the machine. >> >> -Matt >> >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-security" in the body of the message >> > >Cheers, > >Gary > >----------------------------------------------------------- >Gary Gaskell >Manager Secure Network Laboratory Phone (07) 3864 1190 >Information Security Research Centre Fax (07) 3221 2384 >Queensland University of Technology >----------------------------------------------------------- > _--_|\ > / QUT A University for http://www.qut.edu.au/ > _.--._/ the Real World. > v > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19990324234311.00a0eba0>