Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Machine A holds important source data that needs to be backed up. Machine B is where the data will be backed up to. They're both Ubuntu. I want to have an automated process that allows machine A to create an encrypted tarball and copy it to machine B, without human intervention, but doesn't allow anything except copying the file over to a target directory.

I thought about using a chroot jailed account, but this seems to be a pain to set up and overly complex. I really just want to be able to have machine A to copy files to machine B, via automatic cron, but I also want to prevent the mechanism that allows the copy from allowing any other actions (copying to any other directory, logging in, executing any other commands noninteractively, etc.). Also, the transfer must be encrypted (e.g. using ssh somehow).

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

You may want to consider letting B pull tarballs from A rather than have A push them onto B.

Basically a cron job on A would create a tarball, name it uniquely (add a timestamp for example), place it into a directory that B can access (through a restricted account on A) and then have B periodically check that directory and move any files it finds there over to itself.

This setup has an added benefit of not requiring A to have an account on B, meaning that should A get compromised, the attacker would not get a access to B as a freebie.

(edit) For copying over SSH have a look at 'scp' command.

share|improve this answer
1  
I'd considered this exact idea, actually, although possibly by invoking the tarball command remotely when B calls A, rather than prepping it in advance. (It's a once a month kinda thing.) And yeah, scp would be the way to go. This does seem the most plausible, relatively simple solution. Thanks. –  dirtside Apr 9 '11 at 21:12
    
@dirtside: You can then skip scp entirely and use ssh host run-backup > backup-$(date).txz; inside run-backup you would have tar write to stdout without the -f option. –  grawity Apr 9 '11 at 21:18
    
I'd considered that, but part of my backup scheme is to calculate an MD5 hash of the original file before sending it over the network, to reduce the (admittedly highly unlikely) chance of corruption in transit. So it would go: create tar on A, calculate MD5 hash on A, copy both files down to B, delete files from A. –  dirtside Apr 9 '11 at 21:41
    
@dirtside: SSH 2 already does integrity checks of each packet, using hmac-sha1. –  grawity Apr 10 '11 at 9:00
    
I know, but corruption after transit is also a concern (I have a mechanism in place for re-checking the MD5 hashes periodically, to make sure the backups haven't somehow gotten corrupted later on). –  dirtside Jun 8 '11 at 20:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.