[Web4lib] Off-site backups and scripted SCP/SFTP

[Raymond Wood]

Allegedly, on Tue, Jul 25, 2006 at 04:49:25PM -0400, Keith D. Engwall stated:
> On Jul 25, 2006, at 7:36 AM, Keith D. Engwall wrote:
> > I'm curious as to whether anyone is using commercial off-site
> > backups and if so, what service they are using.
> >
> > We've got about 5GB (mostly from our LIS), and would prefer to use
> > SFTP or SCP with keys (because of scripts).
> >
> > Also, I've found some information online about setting up SSH Keys
> > for scripts, but it seems like either
> >
> > a) you have to not password protect the key
> >
> > or
> >
> > b) you have to manually enter the password after a reboot of the
> > computer (using ssh-agent or similar solution)
> >
> > I'm trying to find a third, in between method... where the password
> > is stored somewhere obscure.  Obviously this is still a security
> > risk, but it's at least less of one than using cleartext ftp with
> > the username and password in the script.
> >
> > Any ideas?
[...]
> I've had several suggestions to use SSH, which I do see the benefit
> of.  My question is still, though, how is authentication being handled
> for SSH?
> 
> The choices, to my understanding are:
> 
> 1) authenticate on the fly (no keys)
> 
> 2) use keys with no password protection on the keys
> 
> 3) use keys with password protection on the keys
> 
> Based on my reading, #1 is not scriptable, #2 is a security risk, and
> #3 is only scriptable by jumping through some hoops using ssh-agent,
> which requires manually authenticating the key at some point after a
> reboot.
> 
> Which of these three methods (or other method if I am missing any) are
> people using when they use SSH?
> 
> Thanks,
> Keith

Hi Keith,

IMHO the short answer is #2 with the proviso, as Francis Kayiwa wrote
previously, to limit the ability of the key you use to only whatever
pertinent command is required:
  "To specify a forced command to a system using OpenSSH, one prepends
  'command="some command" to the beginning of the line containing the
  public key." 
This limits the amount of damage that could occur if somehow the key was
compromised.

Now for the longer answer  :-)  It appears that you are nervous about
Option #2, so I took the liberty of digging up an old quotation from one
of our city's venerable *nix gurus that appeared once upon a time in a
post to our local Linux Users Group (LUG) mailing list, and I hope this
list won't mind indulging me a little:
  "A passwordless key is no less secure than including a plaintext
  password in a script, because root on your box could get at the key
  either way, and non-root can't, again either way.

  If you think about it, *any* way of running unattended SSH connections
  can be co-opted by someone who gets root on your box.  It's simply a
  fact of life.  Even if you run a long-lived ssh-agent process and
  require a passphrase at bootup, an intruder who gets root can still
  get at the connection (as long as your machine doesn't reboot...)

  So what you do is create a passwordless key (why not?  May as well
  make life simple once you accept the facts), but strictly limit what
  it can do on the other machine (for example, just fire up rsync in
  read-only mode.)  That way, if someone does break into the SSH client,
  at least the damage it can do on the server is limited.

  You also don't use the key for any other purpose, obviously."
So I think this is probably your best option.  But back to the original
question, which had to do with backups...

First of all I certainly do not think you require any "commercial"
software, as there are many different free software options for you to
choose from.

Secondly, I think that using 'rsync' over ssh is probably the most
efficient backup method if you are going to create/script your own
backup method/solution.

Thirdly, I think you may find it useful to explore a simple and good
piece of backup software that uses these and similar methods, given your
original statement of your requirements.  In this regard, I would
recommend you may want to explore software such as 'rdiff-backup' or
'rsnapshot' (see this article for example:
http://www.debian-administration.org/articles/217).

Anyway, hope that helps -- good luck  :-)

Have fun,
Raymond