Secure On-Line Storage with sshfs and encfs

Ransomware is getting more and more widespread. The time has come for a secure on-line backup. In this article I shortly explain, how to create a secure on-line storage space using Linux and two existing programs sshfs and encfs.

This solution will work for two Unix machines. It might be not the same convenient and functional as existing consumer cloud storage solutions. The advantages are however good security,  standard software used and "trust no one" (TNO) nature of the solution.

On-line storage is useful for backups, file sharing and similar applications for which people use Google Drive, ownCloud, Amazon Glacier and similar.

Instead of paying for the external services or trusting a PHP script (ownCloud) you could convert an existing, maybe your own, SSH server into a convenient on-line TNO storage.

Disclaimer On this web site you might read about or get access to various kinds of software and technology, including but not limited to libraries, operating systems, software for communications, mobile phones and tablets, Android software and Linux, even cars and motorcycles, security and penetration testing software, software used in security research and forensics, some samples of software which can be used (elsewhere) for malicious or illegal purposes. You will read about or be provided with the ways to change it, to operate it and to use it. You might find advice and recommendations, which are only an opinion, and not a legal advice or commercial recommendation..
Bear in mind, please, that everything you do, you do solely at your own risk and responsibility. In no way the author of this web site, information, graphics and other materials presented here or related to it can be made liable or anyhow else responsible for your own actions as well as actions of any third party and their direct or indirect results or consequences with or without the use of this information as well as the software, technology and systems mentioned and/or presented here, no matter if developed by the author or by any third party.
In no way it is guaranteed that you will meet any suitability for any particular purpose, safety, security, legality or even simply functioning of the software and systems described here. You have to make sure each time yourself, whether what you do, is really what you intend to do, and that you are ready to be yourself responsible for. All the recommendations and experiences described here are the opinions of corresponding authors and are to be taken with care and own full responsibility.
The software provided on or through this web site, linked to from this web site or anyhow else related to this web site is provided by the corresponding authors on their own terms. We provide all the software here as is without any guarantees to you. You are responsible for deciding whether it is suitable for you or not. You are also responsible for all direct or indirect consequences of using this software.
Other web sites linked to from the current one are out of the author's control, we can not guarantee anything about their content, its quality or even legality. We can not be liable for any use of the linked to web sites or of the information presented there.
We reasonably try to keep this website running smoothly and to deliver information to the best of our knowledge corresponding to the state of the art at the times when the information is composed, usually presented together with the information, and out of good intents. We can not however guarantee and can not be liable for this website being temporarily or permanently unavailable, presenting unreliable information or software, or any other similar or not malfunctioning or functioning not up to your expectations as well as any consequences which might result from this site's operation.

Install this packages  on the client Linux machine before we start:

sudo apt-get install encfs sshfs

Once installed we can start right away with sshfs.

Using sshfs to mount a remote folder

Supposedly you have SSH access to a server yourdomain.com and access to the /home/john/shared folder this is the way to mount it locally to the mount point ~/shared:

sshfs -o idmap=user -o uid=$UID john@yourdomain.com:/home/john/shared ~/shared

Type your pass-phrase for the SSH key or your password and you are set to go.

The provided options will perform user id mapping so that you have the same access to the locally mounted shared folder as the similarly named user on the server.

After this mount you can just use the remote /home/john/shared folder locally under ~/shared. This is really convenient.

But what if you do not trust the remote server to store your data?

Adding encryption with encfs

Let's use encfs to encrypt the data before it is stored on-line.

What encfs does is it creates an ecnrypted (root-) folder and mounts its (decrypted) content to a given mount point. You can use the folder at the mount point in the same way you use any other unencrypted local folder. Everything written there will be encrypted and stored in the specified encfs root folder.

Once unmounted, encfs has to be mounted back again using the password you give it first time when you create encfs root folder. This is when decryption happens.

What we want to do is to create encfs encrypted folder in the mounted sshfs folder. The remote serveer will only have access to the encrypted by encfs data. Like this we get TNO remote storage.

encfs ~/shared/.encrypted ~/tnostorage

First time when the folders ~/shared/.encrypted and ~/tnostorage have not yet been created the encfs will initialize the encfs-root and ask you for encryption parameters. Feel free to use the paranoia modus (p), the name suggests good security.

The ~/tnostorage shall be also created. You will be asked to set up a password. Make it strong and be sure to remember it to not to lose your data.

Next time you run the encfs command it will ask you for the password. Then it will decrypt the encfs root and mount unencrypted content to ~/tnostorage.

Encfs gotcha: give absolute addresses to encfs if you work outside of your home folder "~" context. For some reason encfs does not work well with relative paths.

Ok, at this point you should have a remote TNO storage!

Let's make it clear once again how it works altogether.

1. Once you write to ~/tnostorage the encfs encrypts your data and stores it encrypted into ~/shared/.encrypted.
2. As sshfs is mounted to ~/shared the encrypted data is immediately sent to the server and is stored there.
3. Nobody should be able to access your data on the server, as it was encrypted on your machine by encfs.
4. Nobody should be able to access your data in-transit as it is protected by encfs and ssh.

Tip: Clever ransomware will encrypt your backup as well, if it is connected to the infected machine (mounted). Make sure that you store SSH keys safely offline! Protect the encfs password. Unmount the sshfs immediately after you do not need it anymore.

Unmounting the secure online storage

Unmounting is to be done in the reverse order. You unmount encfs first and then sshfs.

fusermount -u /home/zaur/HomeBackup/private &&\
fusermount -u /home/zaur/HomeBackup/homedir

if [ $? -eq 0 ]
then
  echo "Success"
else
  echo "Failed" >&2
fi

Once all the basic operations ahve been discussed it is time to go ahead and anlyse what we have achieved here.

Security analysis

Quite a standard final for some of my articles. Let's speak about threats and mitigation.

Ransomware

It can be spreading on your local machine, on your server or both. On your local machine follow the tip above. Unmount the sshfs when you do not need it anymore to keep your backup safe. On the server - make sure your backup is backuped itself (maybe it is a copy of your local machine folder). Well, if both your workstation and your server were encrypted.. you are out of luck, unless you have a third offline or read-only backup. DVD+Rs are so cheap today :)

Untrusted server

You rely on the encfs security to protect your content from the untrusted server. The untrusted server can still conclude about your backup's size, maybe amount of files, modification times, potentially some other metadata based on how encfs is implemented. Read more on encfs security online, and above all, use a strong password for encfs.

In-transit security

The data transferred is in fact double- encrypted: by SSH and by encfs. It should be secure enough, once the SSH is set up right It's beyond this article to explain it, see e.g. here for starters.

Server trust to the user

It might be that the user declines to use encfs and is using SSH to write files in plain text and maybe to execute commands on the server. If the user is not trusted, sandboxing his actions and encrypting the home folder might be a mitigation. If applicable a legal agreement might help avoiding penalties, e.g. for storing illegal content, which the user might store in clear on your server.