I have a simple file server running on a small Ubuntu machine that facilitates file sharing and 2 way folder syncing between my and my girlfriend's 4 computers through SFTP over a private network.
The setup works great for this purpose. I like how simple it is and the idea that I could easily and securely allow access via the internet occasionally. But I want to add at-rest encryption so that if the computer is physically stolen or lost, the data is unreadable; or at least difficult enough for a normal person to access. I don't think I'm valuable enough to consider myself the target of a RAM dump attack, or anything particularly sophisticated.
Q: Is it possible the use the login password or certificate that is used to establish the SFTP connection to give access to an encrypted drive or folder? In a way that is transparent to the client-side software incl. WinSCP and FileZilla, ie no extra log-ins, scripts ect
The OS could/should remain unencrypted so that the machine can boot up without interaction. I assume this rules out full disk encryption of the system drive.
The data pool is over 700GB and this is too much to fit on the current system drive. So it cannot reside in the
/homefolder without purchasing a bigger SSD (unless I move it I suppose). Currently the data resides on a separate internal HDD, so full disk encryption on that drive could be a convenient option. It would also be good if any spinning disk could sleep 98% of the time.
Keys obviously should not reside unencrypted on the system partition making them available via root or a maintenance image.
The system is dual boot Windows and occasionally it will be repurposed for other things. But, most of the time it would just sit there as a file server.
I may configure the machine later to log data from RS232 or IoT sensors while it serves files, so something like freeNAS is probably not ideal.
My first idea is to use the same mechanism as encrypted home directories. There is already a jail and a separate user setup for SFTP. But, after googling all day I can't work out how to set up another encrypted folder that auto unlocks. This is based on the assumption that you can access an encrypted home directory through SFTP, and that the actual user log-in password is used as the encryption key.
The second idea would be to use LUKS on the data drive and somehow pass the login-password as the passphrase or as a key to unlock the passphrase and mount the drive. I think that could involve the user keyring, but again I haven't been able to google my way to setting this up and I suspect the keyring is unlocked through the gnome login, and not something like an SFTP login.
CBHacking's answer steered me towards PAM and that led me to a solution that seems to be working quite well. I would really appreciate answers that assess this solution and raise issues or significant security holes with the configuration
First, I made sure I had an up-to-date copy of the data pool on a different drive and reformatted the file server data drive as a LUKS volume. This was as simple as installing
cryptsetup-luks and going through the motions. I chose to stick with the ext4 file system.
$ apt-get install cryptsetup $ cryptsetup -y -v luksFormat /dev/sda1 $ cryptsetup luksOpen /dev/xvdc somename $ mkfs.ext4 /dev/mapper/somename
The passphrase chosen was a 20 character random string incl numbers and special chars.
Then, to get the drive to mount to my desired location automatically i used pam-mount. IBM and Archlinux provided useful guides, but setting it up in Ubuntu was actually significantly easier than what they documented. After installation
$ apt-get install libpam-mount
the appropriate entries in Login Manager Configuration (the referred changes to files in
/etc/pam.d/ and adding
auth optional pam_mount.so lines) all seem to have been handled by the installer. I did not need to make any changes to files in that directory.
The password for the designated SFTP user account was changed to match the passphrase of the LUKS partition. The long password did make it annoying to log in, but that was only needed a couple of times.
Then a line as simple as this was entered into
/etc/security/pam_mount.conf.xml under the
<! volume description /> line
<volume user="SFTPusername" fstype="crypt" path="/dev/sda1" mountpoint="/dataext/drive" options="fsck,noatime"/>
And thats it. The drive auto mounts to
/dataext/drive on login, which is the root for the SFTP server's chroot jail. I was worried that connecting to SFTP might not count as a 'full login' so to speak and would not invoke things like PAM. But this seems not to be the case, PAM works well. When logging into the GUI directly on the machine with the SFTP user account, I can navigate to the mount point and access the drive without issue. After logging out and logging in as a different user, I can see the drive in Nautilus appearing as a drive unmounted, encrypted and locked. While remaining logged into that account if I pull out a Windows laptop and connect to the SFTP server with WinSCP using the SFTP user account I can see the drive disappear from the list in Nautilus and the file tree appear in WinSCP. Upon closing the connection in WinSCP, the drive immediately appears again in Nautilus locked, encrypted and unmounted.
As highlighted by CBHacking, the security isn't perfect.
- Pre shared keys cannot be used. It is limited to using password authentication which is less sophisticated and requires accepting the unknown key/certificate that is sent by the server on the first log in attempt.
- Data is decrypted and reencrypted on the server as it goes from transit to storage. Possible processing overhead (not sure how significant) and there is the possibility for malware on the server to intercept things. Encryption keys would be in RAM somewhere while active.
- Others I haven't thought of?
But for my need of protecting against physical theft, I think it is well suited.
- Works like it did before; Can be turned on and off with the power button, no extra passwords, can be logged in with standard SFTP client software
- Log-in credentials are protected in transit with SSH
- Data has strong static encryption
- The drive encryption key is not stored unencrypted on the device
- The drive remains unmounted and spun down most of the time, which I assume limits the amount of time the key is in RAM and vulnerable to some attack
If I where using this server strictly for backup, I would probably use Duplicati. This is client side software that de-duplicates, compresses and encrypts the data before it leaves the machine. I already use it to backup onto some external hard drives and it works very well.
Recently needed to make this change to make the power button function with the monitor removed
Appreciate anyone's follow up answers that helps me improve my setup