LUKS-एन्क्रिप्टेड किराए के सर्वर को रिमोटली कैसे अनलॉक करें?

किराए के सर्वर पर रिमोट अनलॉक क्यों मायने रखता है?

क्योंकि एन्क्रिप्टेड ड्राइव हर बूट पर अपनी कुंजी का इंतज़ार करती है, और स्क्रीन पर कोई नहीं होता। ग्राहकों के लिए IPMI या KVM-over-IP तक कोई पहुंच नहीं है; डैशबोर्ड में आपके द्वारा मांगे गए रीबूट और रीइंस्टॉल टीम द्वारा किए जाते हैं।

इसलिए एन्क्रिप्ट करने से पहले अनलॉक की योजना बनाएं। होल्ड पर, ऑपरेटिंग सिस्टम अपने अलग SSD पर रहता है और डेटा ड्राइव खाली मिलती हैं। यही बंटवारा पहला तरीका आसान बनाता है: सिस्टम को सादा रखें, जो ड्राइव आपका डेटा रखती हैं उन्हें एन्क्रिप्ट करें।

जो ड्राइव आपका डेटा रखती हैं उन्हें एन्क्रिप्ट करें; बूट पथ को इतना सरल रखें कि SSH से ठीक किया जा सके।

मैं डेटा ड्राइव को कैसे एन्क्रिप्ट करूं और रीबूट के बाद उन्हें अनलॉक कैसे करूं?

हर डेटा ड्राइव को LUKS2 के रूप में फ़ॉर्मेट करें, उसे खोलें, और खोले गए डिवाइस पर array बनाएं। पासफ्रेज़ कभी सर्वर की डिस्क को नहीं छूता। रीबूट के बाद, सिस्टम आ जाता है, आप SSH से लॉग इन करते हैं, और ड्राइव फिर से खोलते हैं। ऊपर array का चुनाव ZFS या हार्डवेयर RAID पर निर्भर है।

जो सेवाएं pool का इस्तेमाल करती हैं वे आपके ऐसा करने तक इंतज़ार करती हैं। एक बाहरी uptime चेक, या ऐसी स्क्रिप्ट जो pool गायब होने पर अलर्ट दे, आपको बताती है कि रीबूट हुआ था।

apt install cryptsetup
# ZFS tools: zfsutils-linux and zfs-dkms from Debian contrib; built into Proxmox

# once per data drive: this erases it and asks for a passphrase
cryptsetup luksFormat --type luks2 /dev/disk/by-id/ata-MODEL_SERIAL01
cryptsetup open /dev/disk/by-id/ata-MODEL_SERIAL01 data01
# ...repeat for data02, data03, data04

zpool create -o ashift=12 tank raidz2 \
  /dev/mapper/data01 /dev/mapper/data02 /dev/mapper/data03 /dev/mapper/data04

# after every reboot: log in, open each drive, import the pool
cryptsetup open /dev/disk/by-id/ata-MODEL_SERIAL01 data01
# ...repeat for each drive
zpool import tank

क्या ZFS नेटिव एन्क्रिप्शन LUKS की जगह ले सकता है?

हां, प्रति dataset। dataset को encryption=on और एक पासफ्रेज़ के साथ बनाएं, फिर हर रीबूट के बाद zfs load-key और zfs mount चलाएं। कोई initramfs काम की ज़रूरत नहीं है।

हालांकि, यह कम छिपाता है। OpenZFS मैनुअल कहता है कि ZFS pool-संरचना के metadata को एन्क्रिप्ट नहीं करता: dataset और snapshot के नाम, प्रॉपर्टी और फ़ाइल साइज़ पढ़े जा सकते रहते हैं। LUKS पूरी ड्राइव को एन्क्रिप्ट करता है, metadata सहित। दोनों एक ही वादे के अंतर्गत आते हैं: आप हर डेटा ड्राइव को LUKS या ZFS native encryption से एन्क्रिप्ट कर सकते हैं; चाबियाँ आपके पास ही रहती हैं और टीम का कोई भी व्यक्ति उन्हें कभी नहीं मांगता।

Clevis और Tang के साथ ड्राइव को स्वचालित रूप से कैसे अनलॉक करूं?

कहीं और आपके नियंत्रण वाली मशीन पर Tang सर्वर चलाएं, और हर ड्राइव को उससे बाइंड करें। Clevis LUKS में एक नया key slot जोड़ता है और एन्क्रिप्टेड कुंजी को LUKS हेडर में रखता है। बूट पर यह कुंजी वापस पाने में मदद के लिए Tang से पूछता है; आपका पासफ्रेज़ पहले की तरह काम करता रहता है।

Clevis मैनुअल कहता है कि early-boot unlocking केवल root volume को कवर करता है। डेटा ड्राइव late-boot unlocker का इस्तेमाल करती हैं, जो /etc/crypttab पढ़ता है। Debian पर, clevis-systemd पैकेज वहां _netdev से चिह्नित डिवाइस को अनलॉक करता है।

ड्राइव तभी खुलती हैं जब स्टोरेज सर्वर आपके Tang सर्वर तक पहुंच सके। Tang के firewall से केवल स्टोरेज सर्वर का IP पता अनुमति दें। उस नेटवर्क से बाहर जाने वाली ड्राइव लॉक रहती हैं।

# on your Tang machine, not on the storage server
apt install tang
systemctl enable tangd.socket --now

# on the storage server
apt install clevis clevis-luks clevis-systemd
clevis luks bind -d /dev/disk/by-id/ata-MODEL_SERIAL01 tang '{"url": "http://TANG_ADDRESS"}'
# ...repeat for each data drive

# /etc/crypttab, one line per drive:
# data01  /dev/disk/by-id/ata-MODEL_SERIAL01  none  luks,_netdev

systemctl enable clevis-luks-askpass.path

# check the binding, or unlock by hand
clevis luks list -d /dev/disk/by-id/ata-MODEL_SERIAL01
clevis luks unlock -d /dev/disk/by-id/ata-MODEL_SERIAL01

मैं dropbear-initramfs से एन्क्रिप्टेड root को कैसे अनलॉक करूं?

initramfs में एक छोटा SSH server, dropbear, डालें। यह root filesystem से पहले शुरू होता है, आप अपनी key से लॉग इन करते हैं, और cryptroot-unlock passphrase मांगता है। Debian की cryptsetup गाइड headless systems के लिए यही तरीका बताती है।

Debian का README नियम तय करता है। Keys /etc/dropbear/initramfs/authorized_keys में जाती हैं, और password लॉगिन बंद रहता है। Options /etc/dropbear/initramfs/dropbear.conf में जाते हैं। Network driver /etc/initramfs-tools/modules में होना चाहिए, और static address kernel के ip= parameter से सेट होता है। यही paths Debian 12, Debian 13 और Ubuntu 24.04 पर लागू होते हैं।

initramfs अपनी अलग host keys इस्तेमाल करता है, इसलिए आपका SSH client बदली हुई key की चेतावनी देता है। इसके लिए एक अलग known_hosts फ़ाइल रखें, जैसा README सुझाता है।

apt install dropbear-initramfs

# your public key, limited to the unlock command
echo 'no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock" ssh-ed25519 AAAA... you@laptop' \
  > /etc/dropbear/initramfs/authorized_keys

# listen on another port than the main SSH server
echo 'DROPBEAR_OPTIONS="-p 2222"' >> /etc/dropbear/initramfs/dropbear.conf

# static address in the initramfs: client::gateway:netmask::interface:off
# add to GRUB_CMDLINE_LINUX in /etc/default/grub, for example:
# ip=203.0.113.10::203.0.113.1:255.255.255.0::eno1:off
update-grub
update-initramfs -u -k all

# from your computer, at each boot
ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.initramfs [email protected]

encryption क्या सुरक्षित करता है, और क्या नहीं?

यह उन drives की रक्षा करता है जो लॉक हैं: power off, बदलने के लिए निकाली गई, या cancellation के बाद छोड़ी गई। तभी host या कोई और आपकी key के बिना hardware के पास होता है। आपके जाने के बाद drives का क्या होता है, यह cancellation के बाद data पर है।

जब तक server unlocked चलता है, key memory में रहती है। जो लॉग इन कर लेता है वह फिर भी data मिटा सकता है; वह जोखिम immutable backups पर कवर है। जो data server को कभी पढ़ना नहीं है, उसे upload से पहले अपनी मशीन पर encrypt करें; देखें client-side encrypted backups।

2 November 2026 को Basalthold में जांचे गए 23 storage-server विक्रेताओं में, 2 ने delivery से पहले ID मांगी और 12 कुछ triggers पर मांग सकते थे। encryption drives की रक्षा करता है; कोई KYC नहीं: किसी भी समय कोई ID नहीं, कोई सेल्फ़ी नहीं, कोई दस्तावेज़ नहीं, कोई कार्ड नहीं और कोई फ़ोन नंबर नहीं।