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.
Encrypt ZFS pool
- Thread starter axrusar
- Start date
But the whole server is so heavy.
So better bring along the iFixit kit (if even necessary) and take only the drives. 
*SCNR*
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.
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.
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:
So you will be able to break the ProxMox password with the iFixit iHakaPass-SHA256 USB dongle right?But the whole server is so heavy.
*SCNR*
PS.: I agree. Automatically mounting encrypted drives makes the whole purpose somewhat useless; at least halfway.
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?
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?
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.So you will be able to break the ProxMox password with the iFixit iHakaPass-SHA256 USB dongle right?
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.
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.
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:
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
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.
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.
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:
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.