Re: [Duplicity-talk] Re: How to run duplicity with a Cron Job

[Mathias de Riese]

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