BackupPC-users

Re: [BackupPC-users] sshd on client?

2008-12-26 21:32:32
Subject: Re: [BackupPC-users] sshd on client?
From: Holger Parplies <wbppc AT parplies DOT de>
To: "Nils Breunese (Lemonbit)" <nils AT lemonbit DOT com>, gayleard AT eircom DOT net
Date: Sat, 27 Dec 2008 03:29:20 +0100
Hi,

Nils Breunese (Lemonbit) wrote on 2008-12-26 22:00:28 +0100 [Re: 
[BackupPC-users] sshd on client?]:
> Timothy Murphy wrote:
> > Nils Breunese (Lemonbit) wrote:
> >> Timothy Murphy wrote:
> > [...]
> > When you say "you can SSH into the machines"
> > I take that to mean that you can say
> >     ssh <remote machine>
> > I suspect that is what most newbies to backuppc (like me) will think,
> > which is probably why the official documentation is hard to untangle.
> 
> I gave an example that read 'ssh username@client', not 'ssh client'.
> [...]
> > You say it is standard procedure;
> > but it is not normal to ssh into a machine as a different user,
> 
> Why not? You login as the user you want to login as.

actually, ssh is most useful for inter-realm access. On my local intranet,
password and data snooping are not a real threat. I use ssh anyway, out of
habit. But who says my user name for my university account, work account,
home account are all identical? In fact, on my work firewall, I don't have a
dedicated user account, so my .ssh/config contains

        Host firewall
                User root

making 'ssh firewall' equivalent to 'ssh -l root firewall'. You see, it's
quite *natural* to have different user names on client and server side - so
natural that ssh provides a mechanism to save you typing the user name every
time. ssh is as much about accessing user priviledges as it is about accessing
a remote host ('ssh root@localhost'). There is a default available for the
remote user name which turns out to make sense quite often: the local user
name. But this is a short-cut, nothing more. If I had written ssh, I would
have provided a default for the host as well: localhost (which would make the
invocation 'ssh' (without parameters) legal but essentially useless).

> >>> That is what I found to be the essential point in getting BackupPC
> >>> working.
> >>> Amazingly, it did not see to be stated clearly in any of the  
> >>> tutorials

Two points strike me when reading this:

1.) There is an evident misconception of the scope of BackupPC.
    ssh is not part of BackupPC. BackupPC provides about four transfer methods
    ($Conf{XferMethod}): tar, smb, rsync and rsyncd ('BackupPCd' omitted on
    purpose). For network backups (but not local backups!) you need to provide
    a method to bridge the gap between local host and remote host. For smb and
    rsyncd, the protocol itself does this (but you may want to trick it into
    using an ssh tunnel). For tar and rsync, you can use anything that works
    for you.
    Most people probably use ssh, because that is secure and fairly easy to
    set up. I use NFS in one setup - no ssh involved. I could imagine using
    rsh or even netcat in a trusted environment. Or, of course, any
    home-grown protocol that transparently passes data over the network. You
    see that it is impossible to document all conceivable cases, because they
    are essentially site-specific. That is true even for the classic 'rsync
    over ssh' case. Probably all security-conscious people do *not* 'ssh -l
    root ...'. I use the backuppc user on the remote end and then 'sudo' to
    gain root access for the rsync command and that only. So it is specific to
    *your* setup and *your* requirements which access you actually need to
    test. Furthermore, it is documented in *your* configuration files, which
    access is actually used.

2.) You seem to be confusing documentation and third-party web resources.
    I'm not sure which 'tutorials' you are referring to, but I believe the
    BackupPC documentation does not contain any tutorials. Nils quoted from
    the documentation, and it appears to be very clear. If someone puts
    instructions on the web which are maybe unclear (or even misleading), that
    should not be attributed to the quality of the official documentation.

> [...]
> > and in the case of backuppc it is not clear that this is what is  
> > being done,
> > unless one looks "behind the scenes".

As I said, "behind the scenes" means "what *you* configured". If you use the
default values, you will need to understand what they mean. You should at
least have *looked at* the values, in which case you should have noticed the
'ssh -q -x -l root $host ...'.

In fact, if *anything* requiring remote read access to *all your files* *ever*
works out-of-the-box, you should be *very* suspicious. BackupPC's default
configuration *could* contain options to suppress the host key check, but this
would be a Very Bad Thing (tm). Anyone who really understands the meaning of
the host key check will want to actually verify the key fingerprint. Anyone
who does not should be educated. I just doubt many people wanting to set up
BackupPC would really read a lecture on ssh security (and it's really outside
the scope of BackupPC anyway). Being unclear might actually be a virtue,
because it would make more people be willing to read a lecture on ssh
security ;-).

> > In my view, BackupPC is an excellent program,
> > with two large provisos:
> > the documentation is very bad,
> 
> I disagree completely.

So do I. Many more things are explained in the documentation than I ever would
have expected.

You will never be able to document *everything* someone may need to know.
There will always be people who need to be explained how to use a mouse
(browser, shell, editor, ssh ...). 

> Do you  know about the BackupPC wiki? You can post clearer instructions
> there if you have any.

Let me translate this: documentation of an open source project is as much a
responsibility of the user community as it is of the author. If you found
something difficult to understand, change that for future users!

> > and the error messages (the 4 bytes nonsense) are even worse.
> 
> That one might be hard to tackle at first, yes. If you or someone else  
> could contribute a patch that would make this better, by all means let  
> the list know.

There are some errors that are hard to propagate. If rsync says "something
went wrong, and I don't know what it was", what is BackupPC supposed to make
of it? Again: BackupPC doesn't assume you are using ssh (it assumes you have a
transparent data connection, which you don't). Maybe it could, and maybe some
things would work better ... until someone changes the error message in ssh,
or someone uses a different ssh implementation. The virtue of BackupPC is the
freedom it leaves the user in acquiring the tar/rsync data streams.

Regards,
Holger

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/