docs: update ZFS-Commands

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 <your-yubikey-gpg-id> \
-    /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 <challenge> | 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.