From c801f69bf5b1792b6b8e81879bcbb25c687c4e58 Mon Sep 17 00:00:00 2001 From: Administrator Date: Sat, 31 Jan 2026 15:26:12 +0000 Subject: [PATCH] docs: update ZFS-Commands --- ZFS-Commands.md | 150 +----------------------------------------------- 1 file changed, 1 insertion(+), 149 deletions(-) diff --git a/ZFS-Commands.md b/ZFS-Commands.md index f72e133..aa9e11d 100644 --- a/ZFS-Commands.md +++ b/ZFS-Commands.md @@ -2,7 +2,7 @@ title: ZFS Common Commands description: ZFS Commands published: true -date: 2026-01-31T15:23:07.585Z +date: 2026-01-31T15:26:03.716Z tags: zfs commands editor: markdown dateCreated: 2026-01-31T15:23:07.585Z @@ -160,151 +160,3 @@ zfs rollback vault/dataset@snap zfs send | zfs receive arcstat 1 -You said: -can I tie my zfs keys to a ubikey -ChatGPT said: - -Short answer: yes — indirectly, and safely. -ZFS cannot talk to a YubiKey by itself, but you can bind ZFS encryption unlock to a YubiKey-backed secret using standard Linux plumbing. - -There are three sane ways to do this. I’ll rank them from best → worst for a homelab like yours. -🥇 Best option: YubiKey → unlock file → ZFS keylocation=file:// - -This is the most common, reliable, and automation-friendly approach. -How it works (conceptually) - -YubiKey - ↓ (touch / PIN) -Decrypts keyfile - ↓ -ZFS loads dataset key - -ZFS never sees the YubiKey — it just reads a key file that only exists while the YubiKey is present. -Step-by-step (clean + robust) -1️⃣ Generate a random ZFS keyfile - -mkdir -p /root/zfs-keys -chmod 700 /root/zfs-keys - -dd if=/dev/urandom of=/root/zfs-keys/vault.key bs=32 count=1 -chmod 600 /root/zfs-keys/vault.key - -2️⃣ Encrypt that keyfile to the YubiKey - -Using GPG (most flexible): - -gpg --encrypt --recipient \ - /root/zfs-keys/vault.key - -This creates: - -vault.key.gpg - -Then securely delete the plaintext key: - -shred -u /root/zfs-keys/vault.key - -3️⃣ Set ZFS to expect a keyfile - -zfs set keyformat=raw vault/Secret -zfs set keylocation=file:///root/zfs-keys/vault.key vault/Secret - -4️⃣ Unlock procedure (manual or scripted) - -Insert YubiKey → decrypt → load ZFS key: - -gpg --decrypt /root/zfs-keys/vault.key.gpg > /root/zfs-keys/vault.key -zfs load-key vault/Secret -shred -u /root/zfs-keys/vault.key - -✔️ Dataset unlocked -✔️ Keyfile wiped -✔️ YubiKey required every time -5️⃣ Lock again (optional) - -zfs unload-key vault/Secret - -🥈 Alternative: YubiKey challenge–response → derived key - -This uses the YubiKey’s HMAC-SHA1 challenge/response slot. -Pros - - No stored keyfile - - Strong hardware binding - -Cons - - More brittle - - Harder to recover - - Less transparent - -Typical flow: - -ykchalresp -2 | sha256sum | zfs load-key - -⚠️ I only recommend this if you are comfortable with irreversible crypto mistakes. -🥉 Not recommended: YubiKey PIV directly with ZFS - -ZFS: - - ❌ Cannot use PKCS#11 - - ❌ Cannot read smartcards - - ❌ Cannot prompt hardware - -Anything claiming “direct ZFS + YubiKey” is lying or wrapping option #1. -🚨 Critical recovery warnings (read this) - -If you do this: - - 🔒 BACK UP THE ENCRYPTED KEYFILE - - 🔑 Have a second YubiKey - - 🧾 Document the unlock process offline - -Best practice: - -• Primary YubiKey -• Spare YubiKey enrolled to same GPG key -• Encrypted keyfile backup (offline) - -If you lose the YubiKey and the encrypted keyfile: - - The data is permanently unrecoverable - -ZFS encryption is not forgiving. -✅ Recommended pattern for your lab - -Given your setup (servers, NFS, ZFS send, occasional offline use): - - Use file-based keys - - Protect keyfile with YubiKey + GPG - - Unlock only datasets that truly need encryption - - Leave media + Docker unencrypted for sanity - -Example layout: - -vault/Green (unencrypted) -vault/Docker (unencrypted) -vault/Backups (encrypted, YubiKey) -vault/Secrets (encrypted, YubiKey) - -🧠 Want next? - -I can: - - Write a one-command unlock script with safety checks - - Design a boot-time + manual unlock hybrid - - Help you rotate keys or migrate existing encrypted datasets - -Just tell me how automated you want this to be.