From owner-freebsd-security Thu Mar 25 2:22:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from dnai.com (dnai.com [207.181.194.98]) by hub.freebsd.org (Postfix) with ESMTP id E656C14DFA for ; Thu, 25 Mar 1999 02:22:54 -0800 (PST) (envelope-from miket@dnai.com) Received: from einstein (dnai-207-181-255-12.dialup.dnai.com [207.181.255.12]) by dnai.com (8.8.8/8.8.8) with SMTP id CAA12883; Thu, 25 Mar 1999 02:19:29 -0800 (PST) Message-Id: <4.1.19990325021717.0097e980@mail.dnai.com> X-Sender: miket@mail.dnai.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 25 Mar 1999 02:18:35 -0800 To: Matthew Dillon , Gary Gaskell From: Mike Thompson Subject: Re: Kerberos vs SSH Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199903250426.UAA68023@apollo.backplane.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew, Another quick question. Under the configuration described below can one system issue an ssh command from a script to another system without having to include a password? We have automated scripts that will run nightly that will run on one server and execute commands on other servers using ssh. Suppling such a password to the Kerberos kinit application before using ssh in such a script will be problematic. I assume this is why you mentioned your use of the "authorized_keys" files for limited purposes? Any other suggestions? Mike Thompson At 08:26 PM 3/24/99 -0800, 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message