2

For a kind of NAS/server running Ubuntu with SAMBA to host files for several Windows computers, I would like to encrypt the files on the server. I know I could do this for the partition using ZFS or LUKS.

But I have another challenge: Each night I want to sync all changed files into a cloud drive via rsync. In the cloud and before transfer, I want all files to be encrypted. If the complete partition is encrypted, files will appear unencrypted to rsync. Unfortunately rsync does not support synch together with encryption (due to its hash and date algorithms). Thus it would be best to have an unencrypted partition with encrypted files so that rsync can do its job. Having visible file names is not a problem.

Are there any recommendations for how to solve that? I wonder whether SAMBA could do the encryption/decryption or whether there is a file system supporting this. Or maybe there are alternatives to rsync? Cloud Drive supports FTP, SFTP, FTPS, WebDAV, SMB / CIFS with and without VPN, SCP and rsync.

  • Be aware that Full Disk Encryption (encryption on the partition as you call it) is not related to encrypting individual files (before creating a back-up) of these files. Please see my answer for a suggestion on a tool to use. – user258572 Feb 4 '18 at 19:52
  • Is it possible for your service to unmount this storage server partition? Would it be possible on your cloud located server to sustain a full backup of your storage server partition? – dan Feb 5 '18 at 19:55
2

Please take a look at Duplicity, which is a tool commonly used for the exact thing you want to achieve. It can encrypt your files via GPG and it does utilize rsync to create back-ups at some destination.

2

Another alternative is to use EncFS to encrypt your files on NAS. The way EncFS works is on a file level, it stores each file encrypted on your hard drive, and decrypts it on-the-fly when accessed via FUSE-mounted file systems.

Then you can rsync your encrypted directories from the hard disk to the cloud as-is, without using any extra tools.

NB: there are security concerns related to EncFS use (see the Wiki page), but in your use case they seem to be largely irrelevant. If you still consider them relevant, gocryptfs is a successor of EncFS and fixes some of those issues.

-1

I've been trying to achieve something like this for a while now, and a couple days ago I got it working. I am using SSHFS.

Duplicity is nice but if you'd rather stick with simpler tools, my configuration allows you to do what you originally asked for: an encrypted filesystem on a remote server, which you can obtain access to through an encrypted channel, in a convenient enough way for rsync to function.

Whether or not it is secure, is another important consideration. The only problem I've found for this setup is the following: Is it safe to store encrypted volumes on cloud syncing services?

Here is how I configured it:

# setup

ssh remoteserver
cd /srv/storage/
sudo dd if=/dev/zero of=store1 bs=1024 count=1048576 # 1 GB
sudo chown nacht:nacht store1
exit

# make sure /etc/fuse.conf has the "user_allow_other" line uncommented, and that your account can read from this file

sudo mkdir /mnt/securestorage
sudo mkdir /mnt/store1
sudo chown nacht:nacht /mnt/securestorage
sudo chown nacht:nacht /mnt/store1
sshfs remoteserver:/srv/storage /mnt/securestorage -o allow_other
sudo losetup -a # check which loop to use
sudo losetup /dev/loop0 /mnt/securestorage/store1
sudo cryptsetup -y -v luksFormat /dev/loop0
sudo cryptsetup luksOpen /dev/loop0 store1
sudo mkfs -t ext3 -m 1 -v /dev/mapper/store1
sudo mount /dev/mapper/store1 /mnt/store1
cd /mnt/store1
sudo chown nacht:nacht .
echo "test" > test
cat test
cd ..
sudo umount /mnt/store1
sudo cryptsetup luksClose store1
sudo losetup -d /dev/loop0
sudo umount /mnt/securestorage


# turn it on
sshfs remoteserver:/srv/storage /mnt/securestorage -o allow_other
sudo losetup -a # check which loop to use
sudo losetup /dev/loop0 /mnt/securestorage/store1
sudo cryptsetup luksOpen /dev/loop0 store1
sudo mount /dev/mapper/store1 /mnt/store1
cd /mnt/store1

# turn it off
cd /
sudo umount /mnt/store1
sudo cryptsetup luksClose store1
sudo losetup -d /dev/loop0
sudo umount /mnt/securestorage
  • -1 because, by default, modern cryptsetup uses XTS encryption mode which is, as described in the link you posted, quite insecure. Not to mention this will be an incredibly inefficient setup, since you also have to transmit filesystem changes over the network, not just changes to files themselves. You are basically turning a NAS into a SAN (not good over long distances or high latency). – forest Jul 20 '18 at 3:54
  • @forest Good point! I perhaps should have posted this as a question first. – Nacht - Reinstate Monica Jul 20 '18 at 4:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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