Encrypt ZFS pool

Unfortunately i feel pretty pissed off, not with any of you, but with the fact that i could not get to mount the encrypted dataset automatically on startup. I find it hard to believe such a robust piece of software does not provide such a basic feature via the GUI, and so far i could not find any solution via the terminal.
I wasted many days setting up my home server with ProxMox but i will have to pass and use something else.
I found TrueNAS to have this functionality when setting up a dataset, it lets you save the keys and not have to go into the terminal when you are a continent away from home and the power goes off..
And now I would be very interested to know what the point is of encrypting something that is then automatically included again at startup. Those who are interested in your data will be happy if they steal the server.
 
Those who are interested in your data will be happy if they steal the server.

But the whole server is so heavy. o_O So better bring along the iFixit kit (if even necessary) and take only the drives. :cool:
*SCNR* :D

PS.: I agree. Automatically mounting encrypted drives makes the whole purpose somewhat useless; at least halfway.
 
According to TrueNAS benefit with encrypted disks is that you can RMA a faulty drive without the manufacturer being able to read your data. Or you can just throw a dead disk into the recycle bin without wiping or physically destroying it first.
But yeah, thats also not what I want here as it won't help against theft. As soon as someone unplugs the power cable to steal the the whole server or just the disks, everything should be locked again with the key just stored in RAM and nowhere on the persistent disks or TPM.
 
And now I would be very interested to know what the point is of encrypting something that is then automatically included again at startup. Those who are interested in your data will be happy if they steal the server.
Yes.. assuming the server gets stolen / raided / in the wrong hands..

The encrypted dataset should load automatically during startup, and there should not be any un-encrypted text file anywhere to get to it.
The bad actor boots up the server OK.. now he needs to type the ProxMox password in order to see anything. he does not have it.
The bad actor boots a live USB with some linux on it.. he tries to mount the datasets and he gets a prompt to decrypt with a passphrase.

What am i missing here?
 
Yes.. assuming the server gets stolen / raided / in the wrong hands..

The encrypted dataset should load automatically during startup, and there should not be any un-encrypted text file anywhere to get to it.
The bad actor boots up the server OK.. now he needs to type the ProxMox password in order to see anything. he does not have it.
The bad actor boots a live USB with some linux on it.. he tries to mount the datasets and he gets a prompt to decrypt with a passphrase.

What am i missing here?
How does it automatically mount the dataset during startup without a key/passphrase stored somewhere unencrypted? You either need to manually type in your key/passphrase which would be fine or you don't need to do it because its stored there which then won't help anything against theft.

TrueNAS for example just stores the key unencrypted on the system dataset, in case you tell it to automount the datasets, so anyone can read them with access to the console/hardware.
You can tell TrueNAS not to keep an copy of the key but then you need to manually unlock each dataset after a reboot.
 
Last edited:
But the whole server is so heavy. o_O So better bring along the iFixit kit (if even necessary) and take only the drives. :cool:
*SCNR* :D

PS.: I agree. Automatically mounting encrypted drives makes the whole purpose somewhat useless; at least halfway.
So you will be able to break the ProxMox password with the iFixit iHakaPass-SHA256 USB dongle right? :p

Actually i am not THAT naive. and i will be fair and answer my own question in the last post.
I get it, it takes 2 minutes to reset a root password on a Debian server if you get physical access to it.
So, i understand the need to manually type a passphrase each time as the ONLY possible practical curtain to protect data, but i refuse to accept
there is no way to protect the dataset even if this happens. The encrypted dataset should then be protected not only by the passphrase, but also protected against a new root user with a different password than the one that was used when encrypting the dataset. This would eliminate the problem, .... in theory or there is probably another catch 22 in there..

BTW, im not a TrueNAS fanboy or anything, i just pointed the friendly option in the GUI, but so far i am testing it and there are many other things that suck with it. I am trying to decide which one to use.
 
Ok final question then..
There is the FULL ENCRYPTION option in proxmox that you mentioned... what is the difference then that way? you will still need to manually type a password each time the system reboots? And what is the difference if the server gets stolen?
 
So you will be able to break the ProxMox password with the iFixit iHakaPass-SHA256 USB dongle right? :p

Actually i am not THAT naive. and i will be fair and answer my own question in the last post.
I get it, it takes 2 minutes to reset a root password on a Debian server if you get physical access to it.
So, i understand the need to manually type a passphrase each time as the ONLY possible practical curtain to protect data, but i refuse to accept
there is no way to protect the dataset even if this happens. The encrypted dataset should then be protected not only by the passphrase, but also protected against a new root user with a different password than the one that was used when encrypting the dataset. This would eliminate the problem, .... in theory or there is probably another catch 22 in there..

BTW, im not a TrueNAS fanboy or anything, i just pointed the friendly option in the GUI, but so far i am testing it and there are many other things that suck with it. I am trying to decide which one to use.
I don't get that. Root password and encryption key/passphrase are totally unrelated. Even root can't access a encrypted but locked datasets. Thats the point of the encryption. If you don't got the encryption key, there is no way to acsess the data. No matter if you got access to the hardware or to a root account. Only way to get the key as an attacker is to dump the RAM and extract it from there without unplugging the power or getting it from someone by social engineering.
If the key is not only stored in volatile RAM but also somewhere on a persistent disk (like TrueNAS does when you want automount of encrypted datasets) you don't need any root password at all to get the key. You just remove the system disk, put it in another computer, mount it there and you can read every file including the phassphrase without any authentification required. You then can just run "zfs mount -al" and type in that passphrase you got from disk to unlock the encrypted datasets.
Ok final question then..
There is the FULL ENCRYPTION option in proxmox that you mentioned... what is the difference then that way? you will still need to manually type a password each time the system reboots? And what is the difference if the server gets stolen?
The difference is that EVERYTHING except the bootloader is encrypted. And what you need to type in while booting is not the root login, its the encryption key the whole system is encrypted with. This all happens before PVE is even able to boot. Without that passphrase you won't even be able to boot PVE.
And because everything is encrypted it won't help you to remove the disk and put it into another machine. You then just see garbage without that key.


If you like it or not. If you don't need to type in a very long (20+ chars) password somewhere manually, your data won't be protected against theft. Thats how encryption works.

Only option without it would be to use key files on a pen drive or token but then you would need to store that pen drive in a safe after booting because if you don't unplug it again everyone stealing the server also got the key file to unlock it.
 
Last edited:
  • Like
Reactions: Neobin
But if you setup PVE right, it works great. After rebooting the full system is locked. I then just need to open a SSH session (no typing in of the password is required as Keepass stores the RSA key and adds it to pagean as soon as I unlock my password safe) and it will ask me for the passphrase. I then copy and paste it from my Keepass password safe into the ssh client and the root filesystem will be unlocked and PVE boots. On the root filesystem I got the keys for all the datasets so after PVE has finished booting and before starting the guests a script I made will unlock all my datasets and mount them.
Sorry to revive an old thread, but could you elaborate on this? If PVE is not fully booted because your root drive is encrypted, what is listening on port 22 SSH ? Is that run from the proxmox-boot-tool somehow?
 
Sorry to revive an old thread, but could you elaborate on this? If PVE is not fully booted because your root drive is encrypted, what is listening on port 22 SSH ? Is that run from the proxmox-boot-tool somehow?
You need to use the "dropbear-initramfs" package. That will add a dropbear SSH server to your initramfs (which is the thing that boots before PVE boots): https://github.com/openzfs/zfs/tree/master/contrib/initramfs

Unlocking a ZFS encrypted root over SSH​

To use this feature:

  1. Install the dropbear-initramfs package. You may wish to uninstall the cryptsetup-initramfs package to avoid warnings.
  2. Add your SSH key(s) to /etc/dropbear-initramfs/authorized_keys. Note that Dropbear does not support ed25519 keys before version 2020.79; in that case, use RSA (2048-bit or more) instead.
  3. Rebuild the initramfs with your keys: update-initramfs -u
  4. During the system boot, login via SSH and run: zfsunlock
 
That is pretty cool! I do not think I particularly care about encrypting root at this point, but it is amazing to know I could if I wanted to.

Thanks again!
Always better to have full system encryption. Keep in mind that without it you will leak your encrypted VMs/LXCs data. The VM will cache the disks data unencrypted in RAM, which would be fine as the RAM is volatile. But the RAM then mighe be swapped out to your unencrypted swap partition so the data will end up unencrypted on your disks.
And log messages of your LXCs might end up on your hosts syslog which again is unencrypted.
 
Always better to have full system encryption. Keep in mind that without it you will leak your encrypted VMs/LXCs data. The VM will cache the disks data unencrypted in RAM, which would be fine as the RAM is volatile. But the RAM then mighe be swapped out to your unencrypted swap partition so the data will end up unencrypted on your disks.
And log messages of your LXCs might end up on your hosts syslog which again is unencrypted.

I do not use swap, but I take your point, thanks!
 
Sorry to revive an old thread. If you don't want to manually enter the password to unlock when the system starts, then there must be a place to store the key, as #30 said, using dropbear SSH is one of the methods, and another method is to store the key in the TPM. Just like the windows system stores the bitlocker key in the TPM, linux can also do this, but I don't know how to do it.

What I did is to only encrypt the disk where the VM is located, don't encrypting the root partition. When the system starts, if I am at home, I can enter the password in front of the computer. If I am outside, I can access the PVE UI through my home public IP, or some VPN software such as zerotier, so that I can enter the password to unlock the hard drive.
 
Last edited:
another method is to store the key in the TPM. Just like the windows system stores the bitlocker key in the TPM, linux can also do this, but I don't know how to do it.
I personally don't like that option as it only helps with RMAing failed disks and not if the server gets stolen. On windows I always disable it so I am forced to type in my passphrase for bitlocker instead of auto-unlocking of all disks as long as they are connected to my mainboard.

What I did is to only encrypt the disk where the VM is located, don't encrypting the root partition.
But then keep in mind that you might leak sensitive data. Logs of your encrypted LXCs can end up on the unencrypted PVE hosts log files. Encrypted data of a VM is stored in RAM and that RAM might be swapped out to the unencrypted swap partition. Backups of LXCs might temporarily write the LXC data to the unencrypted root filesystem.

I personally like my full system encryption using passphrases.
 
  • Like
Reactions: why-be-banned
I personally don't like that option as it only helps with RMAing failed disks and not if the server gets stolen. On windows I always disable it so I am forced to type in my passphrase for bitlocker instead of auto-unlocking of all disks as long as they are connected to my mainboard.


But then keep in mind that you might leak sensitive data. Logs of your encrypted LXCs can end up on the unencrypted PVE hosts log files. Encrypted data of a VM is stored in RAM and that RAM might be swapped out to the unencrypted swap partition. Backups of LXCs might temporarily write the LXC data to the unencrypted root filesystem.

I personally like my full system encryption using passphrases.
Thanks for your reply, you're right that it's not very safe. However, I'm just storing family photos, and I don't have high security requirements. I just want to prevent thieves from stealing my computer and viewing my photos. I don't need to prevent hackers or the FBI from accessing my files.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!