For more than five years ago, I wrote Peer-to-peer secure, private, remote backup. Today, I put the strategy I developed there in use. The point is that you can securily use an account from a provider that you do not trust. The provider will not be able to see your data.
cryptmount-setup
.sshfs
.Host cjb Hostname shell.cjb.net User ekbrand
ssh-copy-id
to copy the public part of your ssh key to the untrusted account.ssh-copy-id cjb
For root to access a sshfs-mounted directory, the user must have permission to do so. (Yes this is slightly weird).
As root, modify /etc/fuse.conf
and add (or uncomment) user_allow_other
.
# Set the maximum number of FUSE mounts allowed to non-root users. # The default is 1000. # #mount_max = 1000 # Allow non-root users to specify the 'allow_other' or 'allow_root' # mount options. # user_allow_other
As user create a mount-point in your $HOME
, eg
mkdir -p ~/mnt/cjb
As user mount the untrusted account with sshfs
into the newly created mountpoint. Also, if your username on the untrusted host is not the same as on your own box, use the idmap
option of sshfs
.
sshfs -o allow_root,idmap=user cjb: mnt/cjb
In addition to the sshfs
mounted directory, whose contents will be visible by the untrusted provider, cryptmount
will need a directory as a mountpoint for the decrypted content. Here I use a directory directly under $HOME
.
mkdir cjb
Do not try to create the encrypted image-file directly in the sshfs-mounted directory, that will end with a chown command getting "permission denied". Instead create it locally, and transfer it to your shell-account with scp.
cryptmount-setup ------------------------------ cryptmount setup script This program will allow you to setup a secure filing-system that will be managed by "cryptmount". You will be able to select basic features such as the location and size of the filesystem - if you want more advanced features, you should consult the =cryptmount= manual page. cryptmount version 4.1, (C)Copyright 2007-2009 RW Penney cryptmount comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions - see the file 'COPYING' in the source directory. ------------------------------ Each =cryptmount= filesystem is identifed by a short name which is used when mounting or configuring that filesystem. This name should be a single word (without spaces), such as "opaque". Please enter a target name for your filesystem [opaque]: cjb The cjb filesystem can be configured to be owned by a nominated user, who will be able to create top-level files & directories without needing to involve the superuser. Which user should own the filesystem (leave blank for "root") []: hans In order to access the cjb filesystem, it must be mounted on top of an empty directory. Please specify where "cjb" should be mounted [/home/hans/crypt]: /home/hans/cjb The maximum available size of your filesystem needs to be chosen so that enough space can be reserved on your disk. Enter the filesystem size (in MB) [64]: 900 The actual encrypted filesystem will be stored in a special file, which needs to be large enough to contain your entire encrypted filesystem. Enter a filename for your encrypted container [/home/hans/crypto.fs]: /home/hans/backup.img Access to your encrypted filesystem is protected by a key that is kept in a separate small file. The key is locked by a password that you must enter whenever you mount the filesystem. Enter a location for the keyfile [/etc/cryptmount/cjb.key]: ------------------------------ Your filing system is now ready to be built - this will involve: - Creating the directory "/home/hans/cjb" - Creating a 900MB file, "/home/hans/backup.img" - Adding an extra entry ("cjb") in /etc/cryptmount/cmtab - Creating a key-file ("/etc/cryptmount/cjb.key") - Creating an ext3 filingsystem on "/home/hans/backup.img" - Overwriting the backup configuration-file "/etc/cryptmount/cmtab.bckp-setup" If you do not wish to proceed, no changes will be made to your system. Please confirm that you want to proceed (enter "yes") [no]: yes Making mount-point (/home/hans/cjb)... done Creating filesystem container (/home/hans/backup.img)... done Taking backup of =cryptmount= master config-file (/etc/cryptmount/cmtab.bckp-setup)... done Generating filesystem access key (/etc/cryptmount/cjb.key)... Generating random key; please be patient... Enter new password for target "cjb": Confirm password: Formatting encrypted filesystem... Enter password for target "cjb":
scp backup.img cjb:
Change /home/hans/backup.img
into /home/hans/mnt/cjb/backup.img
.
As user I issued cryptmount cjb
and got:
cryptmount cjb
Enter password for target "cjb":
e2fsck 1.41.12 (17-May-2010)
/dev/mapper/cjb: clean, 11/57600 files, 8013/230400 blocks
Now, $HOME/cjb
is a free, secure and on-line backup, ready to be used with tools like unison
or (possibly, but see below for better alternatives) with my favourite: git-annex
.
df /home/hans/cjb Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/cjb 907096 17548 843468 3% /home/hans/cjb
Note, however, that you don't trust the provider, so you should not run ssh from the provider. Therefore, ssh-remote in git-annex
is not what you want.
git-annex
does have it's own methods of dealing with untrusted hosts, git-annex
will only send encrypted files to such hosts, and not run git-annex-shell
there. So, for git-annex
you probably better use the special remote rsync, That requires that the provider offers rsync, and shell.cjb.net
offers rsync
as a free addition which you can manually install.
Simple uni-directional mirroring of files are a better use case for this kind of online backup.
In addition to the private part of your ssh-key, four things are needed on every computer from which you want to access the encrypted backup:
sshfs
(~/mnt/cjb
)cryptmount
(~/cjb
)/etc/cryptmount/cmtab
/etc/cryptmount/cjb.key
Justin, who was kind enough to explain for me how git-annex
really handles untrusted hosts, also noted that multiple clients can be tricky - simultaneous write-access will lead to data corruption. Remeber to only mount this backup-storage from one client at a time.
This made me think about how many computers I have, and what difference that makes. For a person who have only one computer, an free, secure, online storage like this is very convenient (compared to, say, USB-sticks or DVD-RW discs). But for someone like me, with five different computers for slightly different situations/tasks, the problem is not really disk-crashes, (even if I don't backup private stuff on work-machines, I still have at least two machines at home with large enough disks), but rather physical break-ins or fire. Should something like that happen, and all my computers at home would be gone, the key, /etc/cryptmount/cjb.key
is crucial, of course.
Store it encrypted on a computer in another location, or in a gpg-encrypted email.