LUKS ile şifrelenmiş kiralık bir sunucunun kilidini uzaktan nasıl açarım?

Kiralık bir sunucuda uzaktan kilit açma neden önemlidir?

Çünkü şifreli bir disk her açılışta anahtarını bekler ve ekranın başında kimse yoktur. Müşteriler için IPMI veya KVM-over-IP erişimi yoktur; dashboard'da talep ettiğiniz yeniden başlatmalar ve yeniden kurulumlar ekip tarafından gerçekleştirilir.

Öyleyse şifrelemeden önce kilit açmayı planlayın. Bir hold üzerinde işletim sistemi kendi SSD'sinde durur ve veri diskleri boş gelir. Bu ayrım ilk yöntemi kolaylaştırır: sistemi şifresiz bırakın, verilerinizi tutan diskleri şifreleyin.

Verilerinizi tutan diskleri şifreleyin; önyükleme yolunu SSH üzerinden düzeltilebilecek kadar basit tutun.

Veri disklerini nasıl şifrelerim ve yeniden başlatmanın ardından nasıl açarım?

Her veri diskini LUKS2 olarak biçimlendirin, açın ve diziyi açılan aygıtlar üzerine kurun. Parola sunucunun diskine hiç dokunmaz. Yeniden başlatmanın ardından sistem açılır, SSH üzerinden giriş yaparsınız ve diskleri yeniden açarsınız. Üzerine dizinin seçimi ZFS veya donanım RAID konusundadır.

Havuzu kullanan servisler siz bunu yapana kadar bekler. Dışarıdan bir uptime kontrolü ya da havuz eksik olduğunda uyaran bir script, bir yeniden başlatmanın olduğunu size söyler.

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 yerel şifreleme LUKS'in yerini alabilir mi?

Evet, dataset başına. Dataset'i encryption=on ve bir parola ile oluşturun, sonra her yeniden başlatmadan sonra zfs load-key ve zfs mount çalıştırın. Initramfs üzerinde herhangi bir çalışma gerekmez.

Ancak daha azını gizler. OpenZFS kılavuzu ZFS'in havuz yapısı üstverisini şifrelemediğini söylüyor: dataset ve snapshot adları, özellikler ve dosya boyutları okunabilir kalır. LUKS tüm diski, üstveri dahil şifreler. İkisi de aynı vaat kapsamındadır: Her veri diskini LUKS veya ZFS yerel şifrelemesiyle şifreleyebilirsiniz; anahtarlar sizde kalır ve ekipten kimse bunları asla istemez.

Diskleri Clevis ve Tang ile nasıl otomatik açarım?

Başka bir yerde kontrol ettiğiniz bir makinede Tang sunucusu çalıştırın ve her diski ona bağlayın. Clevis, LUKS'e yeni bir anahtar yuvası ekler ve şifreli anahtarı LUKS başlığında saklar. Açılışta Tang'a anahtarı geri kurtarması için sorar; parolanız önceden olduğu gibi çalışmaya devam eder.

Clevis kılavuzu erken önyükleme kilit açmanın yalnızca root birimini kapsadığını söylüyor. Veri diskleri, /etc/crypttab dosyasını okuyan geç önyükleme kilidi açıcısını kullanır. Debian'da clevis-systemd paketi, _netdev olarak işaretlenmiş aygıtların kilidini orada açar.

Diskler yalnızca depolama sunucusu Tang sunucunuza ulaşabildiği sürece açılır. Tang güvenlik duvarından yalnızca depolama sunucusunun IP adresine izin verin. Bu ağdan çıkan diskler kilitli kalır.

# 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

Şifreli bir root'un kilidini dropbear-initramfs ile nasıl açarım?

initramfs içine küçük bir SSH sunucusu, dropbear ekleyin. Kök dosya sisteminden önce başlar, anahtarınızla oturum açarsınız ve cryptroot-unlock parola ifadesini sorar. Debian'ın cryptsetup kılavuzu bunu headless sistemler için açıklar.

Debian README kuralları belirler. Anahtarlar /etc/dropbear/initramfs/authorized_keys içine gider ve parola ile oturum açma kapalıdır. Seçenekler /etc/dropbear/initramfs/dropbear.conf içine gider. Ağ sürücüsü /etc/initramfs-tools/modules içinde olmalıdır ve statik adres çekirdeğin ip= parametresiyle ayarlanır. Aynı yollar Debian 12, Debian 13 ve Ubuntu 24.04 üzerinde geçerlidir.

initramfs kendi host anahtarlarını kullanır, bu yüzden SSH istemciniz değişen anahtar konusunda uyarır. README'nin önerdiği gibi bunun için ayrı bir known_hosts dosyası tutun.

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]

Şifreleme neyi korur, neyi korumaz?

Kilitli diskleri korur: kapatılmış, değişim için sökülmüş veya iptalden sonra geride bırakılmış olsalar bile. İşte o anda anahtarınız olmadan donanımı host veya başka biri elinde tutar. Ayrıldıktan sonra disklere ne olduğu iptal sonrası veriler sayfasında ele alınıyor.

Sunucu kilidi açık çalışırken anahtar bellekte durur. Oturum açan biri yine de veri silebilir; bu risk değiştirilemez yedekler sayfasında ele alınıyor. Sunucunun hiç okuması gerekmeyen veriler için yüklemeden önce kendi makinenizde şifreleyin; bkz. istemci tarafında şifrelenmiş yedekler.

2 November 2026 tarihinde kontrol edilen 23 depolama sunucusu satıcısından Basalthold teslimattan önce kimlik istedi ve 2 tetikleyicilerde bunu talep edebildi; 12 ise isteyemedi. Şifreleme diskleri korur; KYC yok: hiçbir aşamada kimlik, selfie, belge, kart ve telefon numarası yok.