SOLVED Recovery best practice in TrueNAS vs FreeNAS

[hasirak]

Background:
I used to run with FreeNAS-11.3-U5, but lately my encrypted pool would fail to unlock with the passphrase, and I had to use the Geli recovery key each time I would unlock the pool. I took this as a sign to update and are now running a clean install of TrueNAS 13.0-U6. I have recreated the setup that I had in FreeNAS (passphrase encrypted pool), and moved my data over to it. Things seem to be working as expected, but I noticed that Geli encryption is now deprecated, and I couldn't find a way to download any recovery files in the web-ui.

My question:
What is the current best practice to ensure that I don't get locked out of my passphrase encrypted pool? Are there any recovery files I should download, or will this single passphrase always be enough to recover the pool? Let's say some accident physically destroys my server but leaves n-2 disks unharmed (I am using Raid-Z2). If I then placed my remaining disks in a new server, would I then be able to unlock the pool and save my data only with the passphrase?

 

[sretalla]

will this single passphrase always be enough to recover the pool? Let's say some accident physically destroys my server but leaves n-2 disks unharmed (I am using Raid-Z2). If I then placed my remaining disks in a new server, would I then be able to unlock the pool and save my data only with the passphrase?

Yes.

The passphrase is the only way to unlock a passphrase encrypted pool (with ZFS native encryption). Don't lose/forget it.

Pool resilvering doesn't care about encryption with native ZFS encryption (it's just moving around data and parity blocks, not caring what's inside those, encrypted or not, unlocked or not).

 

[hasirak]

Yes.

The passphrase is the only way to unlock a passphrase encrypted pool (with ZFS native encryption). Don't lose/forget it.

Pool resilvering doesn't care about encryption with native ZFS encryption (it's just moving around data and parity blocks, not caring what's inside those, encrypted or not, unlocked or not).

That is good news and just what I was hoping for.
Thank you for helping me out.

 

[winnielinnie]

Sounds like you would benefit from a "multiple keyslot" feature, in the same way that LUKS does it.

Long story short: With LUKS, you can have up to 8 keyslots for a single container. This means up to 8 passphrases and/or keyfiles, all of which can be used to unlock the container. (This allows for backup keyfiles and passphrases, in case you might lose one or find out that you incorrectly remembered your original passphrase.)

There's a feature request for OpenZFS... from 2017. And it's still being discussed as recently as yesterday.

Not to be a bugger, but it's discussions and responses like this which shake my confidence in ZFS. There seems to be a leadership and management grey area. OpenZFS comes off as more "hobbyist" and less "enterprise" when you peek behind the curtain.

 

[hasirak]

Sounds like you would benefit from a "multiple keyslot" feature, in the same way that LUKS does it.

Long story short: With LUKS, you can have up to 8 keyslots for a single container. This means up to 8 passphrases and/or keyfiles, all of which can be used to unlock the container. (This allows for backup keyfiles and passphrases, in case you might lose one or find out that you incorrectly remembered your original passphrase.)

There's a feature request for OpenZFS... from 2017. And it's still being discussed as recently as yesterday.

Interesting reading. I can see how that is useful in some scenarios. It could be nice to be able to give out keys to other administrators (assuming you would be able to revoke a specific key without invalidating the others), but I'm the only one administrating this server so a single passphrase solution suits me well.

By the way, when I first created the pool, a dataset_POOLNAME_keys.json file was created. I assume this key was invalidated when I switched to the passphrase option and thus is safe to delete? Or would it still be valid if I changed back to using a key instead of the passphrase?

Not to be a bugger, but it's discussions and responses like this which shake my confidence in ZFS. There seems to be a leadership and management grey area. OpenZFS comes off as more "hobbyist" and less "enterprise" when you peek behind the curtain.

Being able to secure the data in the case of physical theft is an absolute criteria for me, and I imagine the same goes for many other security oriented users as well, so I'm not to worried that it will be completely unprioritized going forwards, but thanks for the link, I will pay more attention to how this plays out.

 

[winnielinnie]

Or would it still be valid if I changed back to using a key instead of the passphrase?

It would only be valid if you changed back to a keystring and literally copy+pasted the same 64-length HEX string (rather than randomly generating one for you.)

 

[hasirak]

It would only be valid if you changed back to a keystring and literally copy+pasted the same 64-length HEX string (rather than randomly generating one for you.)

Aha, that sounds good, no loose ends there then :)

 

[winnielinnie]

Keep in mind, there is only one time where a master encryption/decryption key is created. This is during the first time you create a new encrypted dataset. As an end-user, you play no part in this. A 256-bit key is randomly generated in the background, which is the one-and-only master key to encrypt/decrypt your data. This is the actual key that encrypts/decrypts data, and it can never be changed. (For obvious reasons, this master key is not stored plainly in the container's header. An encrypted version of it is.)

Rather than memorize a meaningless 256-bit jumble of 1's and 0's, "passphrase-based derivations" are used. This is what allows you to implement a separate key(s), which can be used to decrypt the master key. (This separate key can be forged from a HEX string or passphrase. Technically, even from a JPEG image, which LUKS allows. I believe that with LUKS, it will only use the first megabyte of the file, but don't quote me on this.)



Imagine a glowing, all-powerful diamond crested master key. It has the power to decipher the secrets of the universe.

If you place it inside a normal box, anyone can grab it! And now they have the power!

So instead you want to secure it in a lock-box, which can only be opened with a different key. "How is this 'other' key shaped?" By waving the master key in the air while reciting an incantation. (So you need to have the master key available to create the lock-box's access key.)

This lock-box access key can now unlock the box, in which you can retrieve the master key of the universe. (Keep the access key safe!)

What if you want to change the box's lock and access key? You need to grab the master key and wave it in the air while reciting a new incantation. (Notice how you need to possess the master key to do this again?)