On Wed, Jan 02, 2002 at 03:35:43PM +0800, Patrick Hsieh wrote: > OK. My problem is, if I use rsync+ssh with blank passphrase among > servers to automate rsync+ssh backup procedure without password prompt, > then the cracker will not need to send any password as well as > passphrase when ssh login onto another server, right? > > Is there a good way to automate rsync+ssh procedure without > password/passphrase prompt, while password/passphrase is still requierd > when someone attempts to ssh login? > > > <quote who="Patrick Hsieh"> > > > > > I am sorry I could be kind of off-topic. But I want to know how to > > > cross-site rsync without authentication, say ssh auth.,? > > > > That's the best way. > > > > > I've read some doc. using ssh-keygen to generate key pairs, appending the > > > public keys to ~/.ssh/authorized_hosts on another host to prevent ssh > > > authentication prompt. Is it very risky? Chances are a cracker could > > > compromise one machine and ssh login others without any authentication. > > > > It's not "without authentication" - you're still authenticating, you're > > just using a different means. There's two parts to rsa/dsa authentication > > with ssh; first there's the key, then there's the passphrase. > > > > If a cracker gets your key, that's tough, but they'll need the passphrase to > > authenticate. If you make a key without a passphrase (generally what you'd > > do for scripted rsyncs, etc) then they *only need the key*. So, you should > > keep the data available with passphrase-less keys either read-only or backed > > up, depending on its importance, etc.
Automation with keys stored on machines is better than doing it manually and forgetting to back up. :-) It **does** provide a path by which someone can gain access from one machine to another. Even accounts with minimal privs can be compromised. We happen to be in process of overhauling our backup architecture. We're installing rsyncd (daemons) on the client machines, and initiating rsync -e ssh backups from a dedicated backup machine on a private LAN with non-routable addresses. That machine packages up the backups and spools them off for storage elsewhere. The [modules] in rsyncd.conf provide a nice way to package what you want to back up. You can also specify what ip addresses connect to rsyncd. So in theory only the backup machine can connect to the rsyncd daemons; we've set those to read-only. It **seems** that even though we are pulling the data of with rsync -e ssh there is no need for a key on the server machine. Maybe I was working on it too late last night; at any rate, tcpdump will tell. Can it build an ssh tunnel without keys at both ends? YMMV. The idea is that if someone got root on the client machines, the only additional path they would have to backups is an interface on the private LAN. Not foolproof, but lower hanging fruit elsewhere would be easier picking. cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content/site management, online commerce, internet integration, Debian linux
