On Thu, Apr 26, 2007, Kevin Hunter wrote: >At 11:22a -0400 on 26 Apr 2007, Hal wrote: >>On Apr 26, 2007, at 8:34 AM, Kevin Hunter wrote: >>>In general, utilizing public/private keys for remote >>>authentication is /much/ more secure than passwords. >> >>There is some debate about which is more secure >>public/private keys or username/password. > >Yep, thank you for that reminder. :-) I suppose we now know what >I'm arguing! > >> With public/private keys anyone who has >> access to your machine has access to any machine >> your machine has a key on. > >Without a passphrase, I'd agree. The key word that I made sure to >put in was 'remote'. With passphrases, it becomes a two-step >authentication, one locally to unlock the private key, and one >remotely to at least confirm that you have the other half of the key.
As a rule, we restrict systems to public/private key access with secure shell. On a few systems where people claim they need to use username/password authentication, we restrict access using tcp wrappers to specific systems. One of the biggest problems I see is how to handle things like cron jobs and automatic updates securely without opening up the can of worms of identities without pass phrases. Using rsync modules, restricted to specific hosts is very useful as it permits fine grained control by directory and IP address, and can be done in many cases over insecure channels as updates of existing files with rsync only transmits pieces of the files, not the whole thing. Many of the things we use this for aren't very sensitive information, djbdns data files, postfix configuration, and such. We also use XMLRPC with https to control some things such as running make in the /etc/postfix directory where we have the Makefile set up to rebuild anything necessary as changes are made. We have an XMLRPC server (written in python not php thank you very much :-), which is accessible under the normal Apache restricted security. This server has a limited set of procedures than can do things like restrict access based on the IP address of the client. This server can then make an XMLRPC call to another XMLRPC server running with root priviledges on localhost to do the processing. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 ``People from East Germany have found the West so confusing. It's so much easier when you have only one party.'' -- Linus Torvalde, Linux Expo Canada when asked about confusion over many Linux distributions. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"