[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Re: How to run duplicity with a Cron Job
From: |
Mathias de Riese |
Subject: |
Re: [Duplicity-talk] Re: How to run duplicity with a Cron Job |
Date: |
Tue, 22 Feb 2005 13:06:36 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 |
Hi again,
oh, i forgot: I use ssh with a key in authorized_keys for a special
backup-user on the
backup server. This user has a restricted login shell which is only
allowed to execute
commands duplicity normally uses. I.e. not 'rm'. If anyone is interested
in this restricted
shell, i could send it to him personally -- though in this case i
wouldnt really like to
make it public.
So lets summarize this aspect of my config with the one from my previous
mail:
I have an unprotected private GPG key which is only used for signing and
an unprotected
SSH private key which is only used for logging into the speical account
on the server.
(Unprotected means: Not encryped with a passphrase.) Neither of these
two keys is used
for any other purpose. Encryption of the data is done with a different
public key. So no
passphrase needed for encryption, but a secure private key is needed for
recovery --
which is usually done interactively anyways.
This is the best i could think of when using any kind of common Network
protocoll --
independently of whether you use duplicity or not.
It also requires a configurable server, i.e. root access for the
installation and the
possibility to create new accounts. Otherwise it need not be trusted
very much -- if
someone has root access to the server he can delete your files, of
course. If you
only have a user account, you could in principle still implement some
kind of restricted
shell access via the SSH authorized_keys file: It has a "command="
option. Unfortunately,
sshd does not pass any kind of command-line options to that command, so
a modification
of duplicity would be needed. An example where it works out of the box
is CVS: Put command=cvs
in front of the key of a person who should only use cvs on that
host/account and not be able
to log in...
If you dont trust root on the client you are out of luck anyways. For
that you would need
a server-initiated backup and whatnot. Didnt think much about it.
If you dont trust the users on the client you are save even with a
PASSPHRASE= in crontab --
assuming sensible access-rights to the crontab. If you have less trust
in your clients than
in the server and you have a big site with some kind of AFS/kerberos...
you could use acron
or k5cron. I dont really know much about that. Only that: There, you
have a central server
guarding your tokens/tickets and also a global crontab which contains an
additional column for
the hostname the cron job has to run on. At the time the job is supposed
to run, the server logs
into this host with the help of the token/ticket and runs the job. I
dont know much more about it,
though...
Guess this was enough for now... Let me know, anybody, if you need my
patch for the
public-key-only encryption described in my previous mail. Is it already
integrated or
fixed in the current version? Yo no se.
Cheers,
Mathias