Re: Best way to duplicate HDs--talk more about rsync+ssh system
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 cfm@maine.com
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
Reply to: