At-rest encryption. Use SFTP log-in credentials to unlock/decrypt encrypted drive or folder on an Ubuntu Linux server

Question

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

1. 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.

2. The data pool is over 700GB and this is too much to fit on the current system drive. So it cannot reside in the /home folder 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.

3. Keys obviously should not reside unencrypted on the system partition making them available via root or a maintenance image.

4. 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.

5. 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.

SOLUTION 21/10/2021

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

Answer 1

For Linux, you probably want to use any file or volume encryption method (such as fscrypt or possibly dm-crypt) that supports a PAM module for automatically unlocking when you log in. See e.g. fscrypt for info about how it works and what you can do with it. The short version is that you'd need to configure your chosen system with PAM integration, and then encrypt the data in such a way that the specified user(s) can decrypt it.

Note that PAM isn't used for public key authentication. You'd have to log into the server using password/challenge-response authentication, rather than public key authentication, so that PAM gets your password and can pass it to the encryption layer.

Additionally, such encryption layers are likely not going to be very compatible with Windows, even to the extent that the underlying file systems (e.g. EXT4) are (which is none by default, but there are third-party file system drivers). However, using WSLv2 (which is actually a lightweight Linux VM plus some interoperability features) you could mount the drive and access it through Windows if that was needed.

---

It's also possible to do this with Windows (out of the box requires 10+, Pro or better edition). The one notable advantage of doing this is that you'd be able to use public key authentication in a way that, since it's integrated with Windows authentication, should support automatically unlocking the encrypted files.

1. Enable the Windows SSH server (it's disabled by default).
2. Configure login permissions as you want them (it's a port of OpenSSH plus some stuff to integrate with Windows auth mechanisms).
3. Encrypt the volume / directory where the files are stored using Encrypting File System (EFS), including recursively. Make sure it's giving access to both users (assuming you use different accounts for the SFTP server). Anybody with access to the files can encrypt files to additional users, and it should do so by default according to the ACLs of the directory.

The included cipher.exe command may help here; you can enable EFS using the GUI but the command-line tool gives more control.

Note that this does require the file system to be NTFS; EFS isn't supported FAT-based or third-party systems. If the data is currently on a FAT system then you can use Windows' included convert.ext utility to convert the volume to NTFS (irreversibly), but if it's on anything else (e.g. EXT4) you'll have to copy it off to another volume. Linux support for EFS is AFAIK minimal (there's https://www.systutorials.com/docs/linux/man/8-ntfsdecrypt/ but it's not at all transparent), so it would be inconvenient to access those files while the server is booted into Linux.