[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,

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]