Membuka kunci wadah LUKS root secara otomatis setelah boot panas

Mengapa orang umumnya mengenkripsi drive dari komputer pribadi mereka, dan kadang-kadang server? Jelas tidak ada yang mencuri foto kucing kesayangan mereka dari disk! Itu hanya nasib buruk: drive yang dienkripsi mengharuskan Anda memasukkan frasa kunci dari keyboard di setiap boot, dan itu panjang dan membosankan. Untuk menghapusnya sehingga setidaknya kadang-kadang tidak perlu merekrutnya. Ya, agar makna enkripsi tidak hilang.

Nah, benar-benar menghapusnya tidak akan berhasil. Sebagai gantinya Anda dapat membuat file kunci pada USB flash drive, dan itu juga akan berfungsi. Dan tanpa flash drive (dan tanpa komputer kedua di jaringan) apakah mungkin? Jika Anda beruntung dengan BIOS, Anda hampir bisa! Di bawah potongan akan menjadi panduan tentang cara mengkonfigurasi enkripsi disk melalui LUKS dengan properti berikut:

1. Frasa sandi atau file kunci tidak disimpan di mana pun dalam bentuk terbuka (atau dalam bentuk yang setara dengan terbuka) saat komputer dimatikan.
2. Pertama kali Anda menyalakan komputer, Anda harus memasukkan frasa sandi.
3. Pada reboot berikutnya (sebelum mematikan), frasa sandi tidak diperlukan.

Instruksi telah diuji pada CentOS 7.6, Ubuntu 19.04 dan openSUSE Leap 15.1 di mesin virtual dan pada perangkat keras nyata (desktop, laptop dan dua server). Mereka harus bekerja pada distribusi lain yang memiliki versi Dracut yang berfungsi.

Dan ya, dengan cara yang baik, ini seharusnya berakhir di hub "administrasi sistem abnormal", tetapi tidak ada hub seperti itu.

Saya sarankan menggunakan slot terpisah di wadah LUKS dan menyimpan kunci untuk itu ... di RAM!

BIOS pada kebanyakan motherboard tidak membersihkan memori selama reboot, atau Anda dapat mengonfigurasinya menjadi tidak bersih (pengecualian yang dikenal: "Intel Corporation S1200SP / S1200SP, BIOS S1200SP.86B.03.01.0042.013020190050 01/30/2019"). Karena itu, Anda dapat menyimpan kunci di sana. Ketika daya dimatikan, isi RAM itu sendiri akan dihapus setelah beberapa saat, bersama dengan salinan kunci yang tidak dilindungi.

Jadi ayo pergi.

Langkah satu: instal sistem pada disk yang dienkripsi menggunakan LUKS

Dalam kasus ini, partisi disk (misalnya, /dev/sda1 ) yang dipasang di /boot harus tetap tidak dienkripsi, dan partisi lain tempat segalanya (misalnya, /dev/sda2 ) harus dienkripsi. Sistem file pada partisi terenkripsi dapat berupa apa saja, Anda juga dapat menggunakan LVM sehingga sistem file root, volume untuk swap, dan semua yang lain kecuali /boot dalam wadah yang sama. Ini sesuai dengan partisi disk default di CentOS 7 dan Debian ketika memilih opsi enkripsi. SUSE melakukan semuanya secara berbeda (mengenkripsi /boot ) dan karenanya membutuhkan partisi manual dari disk.

Hasilnya harus seperti berikut ini:

 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 10G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 9G 0 part └─luks-d07a97d7-3258-408c-a17c-e2fb56701c69 253:0 0 9G 0 crypt ├─centos_centos--encrypt2-root 253:1 0 8G 0 lvm / └─centos_centos--encrypt2-swap 253:2 0 1G 0 lvm [SWAP] 

Dalam hal menggunakan UEFI, juga akan ada Partisi Sistem EFI.

Untuk pengguna Debian dan Ubuntu: ganti paket initramfs-tools dengan dracut .

 # apt install --no-install-recommends dracut 

initramfs-tools mengimplementasikan logika yang salah dalam kasus kami, diterapkan pada bagian terenkripsi dengan file kunci. Bagian tersebut diabaikan sepenuhnya, atau konten file kunci disalin ke initramfs (mis., Sebagai hasilnya, ke disk) di tempat kosong, yang tidak kita perlukan.

Langkah dua: buat file kunci yang akan digunakan untuk membuka kunci drive secara otomatis setelah reboot panas

128 bit acak sudah cukup untuk kita, yaitu 16 byte File akan disimpan pada disk terenkripsi, sehingga tidak ada orang yang tidak tahu kunci enkripsi dan tidak memiliki akses root ke sistem yang dimuat tidak akan membacanya.

 # touch -m 0600 /root/key # head -c16 /dev/urandom > /root/key 

Ada cukup banyak bit acak dalam file kunci sehingga algoritma PBKDF yang lambat, yang membuat kunci enkripsi yang sulit untuk dipilih dari frase kunci yang berpotensi lemah, tidak benar-benar diperlukan. Karena itu, ketika menambahkan kunci, Anda dapat mengurangi jumlah iterasi:

 # cryptsetup luksAddKey --key-slot=6 --iter-time=1 /dev/sda2 /root/key Enter any existing passphrase: 

Seperti yang Anda lihat, file kunci disimpan pada disk terenkripsi dan karenanya tidak menimbulkan risiko keamanan jika komputer dimatikan.

Langkah Tiga: Alokasikan ruang dalam memori fisik untuk menyimpan kunci

Linux memiliki setidaknya tiga driver berbeda yang memungkinkan Anda untuk mengakses memori fisik di alamat yang diketahui. Ini adalah linux/drivers/char/mem.c , yang juga bertanggung jawab untuk perangkat /dev/mem , serta modul phram (mengemulasikan chip MTD, memberikan perangkat /dev/mtd0 ) dan nd_e820 (digunakan saat bekerja dengan NVDIMM, memberikan /dev/pmem0 ). Mereka semua memiliki fitur yang tidak menyenangkan:

• /dev/mem tidak dapat ditulis ketika menggunakan Secure Boot jika distribusinya menggunakan patch LOCKDOWN dari Matthew Garrett (dan set patch ini diperlukan jika distribusi akan mendukung Secure Boot dengan bootloader yang ditandatangani oleh Microsoft);
• phram tidak tersedia di CentOS dan Fedora - pengelola tidak mengaktifkan opsi yang sesuai saat membangun kernel;
• nd_e820 perlu mencadangkan setidaknya 128 megabita memori - ini adalah cara kerja NVDIMM. Tetapi ini adalah satu-satunya opsi yang berjalan pada CentOS dengan Secure Boot.

Karena tidak ada opsi yang ideal, ketiganya dipertimbangkan di bawah ini.

Saat menggunakan salah satu metode, sangat diperlukan kehati-hatian agar tidak memengaruhi perangkat atau rentang memori selain dari yang diperlukan. Ini terutama berlaku untuk komputer yang sudah memiliki chip MTD atau modul NVDIMM. Yaitu, /dev/mtd0 atau /dev/pmem0 mungkin bukan perangkat yang sesuai dengan area memori yang disediakan untuk menyimpan kunci. Penomoran perangkat yang ada, di mana file konfigurasi dan skrip bergantung, mungkin juga bingung. Dengan demikian, Anda disarankan untuk menonaktifkan sementara semua layanan yang bergantung pada perangkat yang ada /dev/mtd* dan /dev/pmem* .

Memori fisik Linux memmap dengan meneruskan opsi memmap ke memmap . Kami tertarik pada dua jenis opsi ini:

• memmap=4K$0x10000000 cadangan memmap=4K$0x10000000 (mis., tanda dicadangkan sehingga kernel itu sendiri tidak menggunakan) 4 kilobyte memori, mulai dari alamat fisik 0x10000000;
• memmap=128M!0x10000000 menandai 128 megabita memori fisik, dimulai dengan alamat 0x10000000, sebagai NVDIMM (jelas palsu, tetapi itu akan berlaku untuk kami).

Opsi c $ cocok untuk digunakan dengan /dev/mem dan phram , opsi c ! - untuk nd_e820 . Saat menggunakan $ alamat awal dari memori yang dicadangkan haruslah kelipatan 0x1000 (mis. 4 kilobyte), saat menggunakan ! - kelipatan 0x8000000 (mis. 128 megabita).

Penting: tanda dolar ( $ ) dalam file konfigurasi GRUB adalah karakter khusus dan harus diloloskan. Dan dua kali: sekali - ketika menghasilkan grub.cfg dari /etc/default/grub , kedua kalinya - ketika mengartikan file konfigurasi yang dihasilkan pada tahap boot. Yaitu di /etc/default/grub , baris berikut pada akhirnya akan muncul:

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 ...  ..." 

Tanpa dua kali lolos dari tanda $ , sistem tidak akan bisa boot, karena akan berpikir bahwa ia hanya memiliki 4 kilobyte memori. Tidak ada kesulitan seperti itu dengan tanda seru:

 GRUB_CMDLINE_LINUX="memmap=128M!0x10000000 ...  ..." 

Kartu memori fisik (dan diperlukan untuk mengetahui alamat mana yang harus dipesan) dapat diakses oleh root di /proc/iomem pseudo /proc/iomem :

 # cat /proc/iomem ... 000f0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-7ffddfff : System RAM 2b000000-350fffff : Crash kernel 73a00000-7417c25e : Kernel code 7417c25f-747661ff : Kernel data 74945000-74c50fff : Kernel bss 7ffde000-7fffffff : reserved 80000000-febfffff : PCI Bus 0000:00 fd000000-fdffffff : 0000:00:02.0 ... 

RAM ditandai sebagai "RAM Sistem", cukup bagi kami untuk memesan salah satu halamannya untuk menyimpan kunci. Menebak bagian mana dari memori BIOS yang tidak menyentuh saat reboot tidak akan bekerja dengan baik sebelumnya. Kecuali jika ada komputer lain dengan versi BIOS yang persis sama dan konfigurasi memori yang sama dengan yang telah dilakukan manual ini. Oleh karena itu, dalam kasus umum, perlu untuk bertindak dengan coba-coba. Sebagai aturan, ketika BIOS reboot, itu hanya mengubah data di awal dan di akhir setiap rentang memori. Biasanya cukup untuk mundur 128 megabita ( 0x8000000 ) dari tepi. Untuk mesin virtual KVM dengan memori 1 GB atau lebih, opsi yang diusulkan ( memmap=4K$0x10000000 dan memmap=128M!0x10000000 ) berfungsi.

Saat menggunakan modul phram , phram membutuhkan parameter baris perintah kernel lain, yang, pada kenyataannya, memberi tahu modul bagian mana dari memori fisik yang akan digunakan - kita, disediakan. Parameter disebut phram.phram dan berisi tiga bagian: nama (sewenang-wenang hingga 63 karakter, akan terlihat di sysfs ), alamat awal dan panjangnya. Alamat dan panjang awal harus sama dengan di memmap , tetapi akhiran K dan M tidak didukung.

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 phram.phram=savedkey,0x10000000,4096 ..." 

Setelah mengedit /etc/default/grub Anda perlu membuat ulang file konfigurasi nyata yang dibaca GRUB saat boot. Perintah yang benar untuk ini tergantung pada distribusi.

 # grub2-mkconfig -o /boot/grub2/grub.cfg # CentOS (Legacy BIOS) # grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg # CentOS (UEFI) # update-grub # Debian, Ubuntu # update-bootloader --reinit # SUSE 

Setelah memperbarui konfigurasi GRUB, komputer harus di-boot ulang, tetapi kami akan melakukannya nanti ketika kami memperbarui initramfs.

Langkah keempat: konfigurasikan LUKS untuk membaca kunci dari memori

Pengaturan enkripsi /etc/crypttab disimpan dalam file /etc/crypttab . Setiap baris terdiri dari empat bidang:

• perangkat yang harus diperoleh saat membuka kunci,
• perangkat terenkripsi
• tempat mendapatkan file kunci ( none artinya memasukkan frasa kunci dari keyboard),
• bidang opsional untuk opsi.

Jika file kunci ada, tetapi tidak cocok, maka Dracut meminta frasa kunci. Yang mana, pada kenyataannya, akan diminta pada saat boot pertama.

Contoh file /etc/crypttab dari distribusi yang baru diinstal:

 # cat /etc/crypttab #   luks-d07....69 UUID=d07....69 none 

File kunci dalam kasus kami adalah sepotong memori fisik. Yaitu /dev/mem , /dev/mtd0 atau /dev/pmem0 , tergantung pada teknologi akses memori yang dipilih. Opsi diperlukan untuk menunjukkan bagian file mana yang kuncinya.

 # cat /etc/crypttab #   #   /dev/mem: luks-d07....69 UUID=d07....69 /dev/mem keyfile-offset=0x10000000,keyfile-size=16 #   phram: luks-d07....69 UUID=d07....69 /dev/mtd0 keyfile-size=16 #   nd_e820: luks-d07....69 UUID=d07....69 /dev/pmem0 keyfile-size=16 

Hanya saja itu tidak akan bekerja seperti itu.

Intinya adalah bagaimana systemd menentukan kapan suatu perangkat dapat dibuka kuncinya. Yaitu, ia mengambil perangkat dari kolom ketiga dan menunggu unit perangkat yang sesuai untuk menjadi aktif. Tampaknya logis: tidak masuk akal untuk mencoba membuka kunci wadah LUKS sampai perangkat dengan file kunci muncul. Tetapi unit perangkat tidak sama dengan perangkat itu sendiri. Systemd secara default membuat unit perangkat hanya untuk perangkat kernel yang terkait dengan subsistem perangkat blok dan antarmuka jaringan. Perangkat /dev/mem dan /dev/mtd0 adalah karakter per karakter, oleh karena itu mereka tidak dipantau secara default dan tidak akan pernah diakui sebagai siap.

Kita harus memberi tahu systemd bahwa ia harus melacaknya dengan membuat aturan udev di file /etc/udev/rules.d/99-mem.rules :

 # /dev/mem KERNEL=="mem", TAG+="systemd" # /dev/mtd* KERNEL=="mtd*", TAG+="systemd" #  /dev/pmem*       

Langkah Kelima: Regenerasi initramfs

Saya mengingatkan Anda: artikel ini hanya membahas distribusi menggunakan Dracut. Termasuk yang tidak digunakan secara default, tetapi dapat diakses dan efisien.

Anda perlu membuat ulang initramfs untuk memperbarui file /etc/crypttab sana. Dan juga - untuk memasukkan modul kernel tambahan dan aturan udev di sana. Jika tidak, perangkat /dev/mtd0 atau /dev/pmem0 tidak akan dibuat. Parameter konfigurasi force_drivers Dracut bertanggung jawab untuk mengaktifkan dan memuat modul kernel tambahan, dan install_items bertanggung jawab untuk file tambahan. Kami membuat file /etc/dracut.conf.d/mem.conf dengan konten berikut (spasi setelah tanda kutip pembuka diperlukan, ini adalah pemisah):

 #   /dev/mem: install_items+=" /etc/udev/rules.d/99-mem.rules" #   phram: install_items+=" /etc/udev/rules.d/99-mem.rules" force_drivers+=" phram" #   nd_e820: force_drivers+=" nd_e820 nd_pmem" 

Sebenarnya initramf regenerasi:

 # dracut -f 

Untuk pengguna Debian dan Ubuntu, pengelola membuat rake: file yang dihasilkan disebut salah. Anda perlu mengganti nama sehingga namanya sama seperti yang ditentukan dalam konfigurasi GRUB:

 # mv /boot/initramfs-5.0.0-19-generic.img /boot/initrd.img-5.0.0-19-generic 

Saat memasang kernel baru, pembuatan initramf otomatis melalui Dracut dilakukan dengan benar, bug hanya mempengaruhi peluncuran manual dracut -f .

Langkah Enam: Nyalakan Ulang Komputer Anda

Diperlukan reboot untuk perubahan pada konfigurasi GRUB dan Dracut agar dapat berlaku.

 # reboot 

Pada tahap ini, tidak ada kunci dalam memori, jadi Anda harus memasukkan kata sandi.

Setelah mem-boot ulang, Anda perlu memeriksa apakah cadangan memori berfungsi dengan benar. Minimal, dalam file /proc/iomem pseudo /proc/iomem memori yang diperlukan harus ditandai sebagai "dicadangkan" (saat menggunakan /dev/mem atau phram ) atau sebagai "Memori Persisten (warisan)".

Saat menggunakan phram atau nd_e820 Anda perlu memastikan bahwa perangkat /dev/mtd0 atau /dev/pmem0 benar-benar merujuk pada bagian memori yang sebelumnya dipesan, dan bukan ke hal lain.

 # cat /sys/class/mtd/mtd0/name #  : "savedkey" # cat /sys/block/pmem0/device/resource #     

Jika ini bukan masalahnya, Anda perlu menemukan mana dari perangkat /dev/mtd* atau /dev/pmem* "milik kita", dan kemudian perbaiki / etc / crypttab, buat kembali initramfs dan periksa kembali hasilnya setelah reboot lagi.

Langkah ketujuh: konfigurasikan menyalin file kunci ke memori

File kunci akan disalin ke memori sebelum reboot. Salah satu cara untuk menjalankan perintah apa pun pada tahap shutdown sistem adalah dengan mendaftarkannya di direktif ExecStop dalam layanan systemd. Agar systemd memahami bahwa ini bukan daemon dan tidak bersumpah pada kurangnya arahan ExecStart , Anda perlu menentukan jenis layanan sebagai oneshot dan juga menyarankan bahwa layanan ini dianggap berjalan, bahkan jika tidak ada proses kerja yang terkait dengannya. Jadi, inilah file /etc/systemd/system/savekey.service . Penting untuk meninggalkan hanya satu dari varian yang diberikan dari arahan ExecStop .

 [Unit] Description=Saving LUKS key into RAM Documentation=https://habr.com/ru/post/457396/ [Service] Type=oneshot RemainAfterExit=true #   /dev/mem: ExecStop=/bin/sh -c 'dd if=/root/key of=/dev/mem bs=1 seek=$((0x10000000))' #   /dev/mtd0: ExecStop=/bin/dd if=/root/key of=/dev/mtd0 #   /dev/pmem0: ExecStop=/bin/dd if=/root/key of=/dev/pmem0 [Install] WantedBy=default.target 

Konstruksi dengan /bin/sh diperlukan karena dd tidak mengerti notasi heksadesimal.

Kami mengaktifkan layanan, periksa:

 # systemctl enable savekey # systemctl start savekey # reboot 

Selama reboot berikutnya, Anda tidak harus memasukkan frasa sandi dari disk. Dan jika perlu, ini biasanya berarti bahwa alamat awal area memori yang dipesan dipilih secara tidak benar. Tidak apa-apa untuk memperbaiki dan membuat ulang beberapa file dan me-restart komputer dua kali.

Saat menggunakan phram atau nd_e820 hanya konfigurasi GRUB yang harus diedit. Saat menggunakan /dev/mem alamat awal juga disebutkan di /etc/crypttab (oleh karena itu, initramfs harus dibuat ulang) dan di layanan systemd.

Tapi itu belum semuanya.

Masalah keamanan

Setiap diskusi tentang masalah keamanan didasarkan pada model ancaman. Yaitu pada tujuan dan sarana penyerang. Saya sadar bahwa beberapa contoh di bawah ini tidak masuk akal.

Situasi dengan akses fisik ke komputer yang dimatikan tidak berbeda dari yang tanpa penyimpanan kunci yang dikonfigurasi dalam memori. Ada jenis serangan yang sama yang bertujuan untuk mendapatkan frasa kunci, termasuk Evil Maid , dan fitur keamanan yang sama. Kami tidak berhenti pada mereka, karena tidak ada yang baru.

Situasi yang lebih menarik adalah ketika komputer dihidupkan.

Situasi 1 . Penyerang tidak memiliki akses fisik ke komputer, tidak tahu frasa sandi, tetapi memiliki akses root melalui ssh. Tujuannya adalah kunci untuk mendekripsi disk. Misalnya, untuk mengakses cadangan sektor per sektor lama dari citra disk mesin virtual.

Sebenarnya, kunci pada piring ada di file /root/key . Pertanyaannya adalah bagaimana ini berhubungan dengan apa yang terjadi sebelum pelaksanaan instruksi ini. Jawab: untuk luks1, ancamannya bukan hal baru. Ada dmsetup table --target crypt --showkeys yang menunjukkan kunci master, yaitu juga data yang memungkinkan akses ke cadangan lama. Untuk luks2, penurunan keamanan dalam skenario ini benar-benar terjadi: kunci dm-crypt disimpan di gantungan kunci di tingkat kernel, dan tidak mungkin untuk melihatnya dari userspace.

Situasi 2 . Penyerang dapat menggunakan keyboard dan melihat layar, tetapi tidak siap untuk membuka kasing. Misalnya, saya menggunakan kata sandi yang bocor dari IPMI atau mencegat sesi noVNC di cloud. Dia tidak tahu frasa kunci, dia juga tidak tahu kata sandi lain. Tujuannya adalah akses root.

Tolong: reboot melalui Ctrl-Alt-Del , menambahkan opsi kernel init=/bin/sh melalui GRUB selesai. Frasa sandi tidak diperlukan, karena kunci berhasil dibaca dari memori. Untuk melindungi diri dari ini, Anda harus mencegah GRUB memuat apa yang tidak ada pada menu. Sayangnya, fungsi ini diterapkan secara berbeda dalam distribusi yang berbeda.

Dimulai dengan versi 7.2, CentOS memiliki perintah grub2-setpassword , yang sebenarnya melindungi GRUB dengan kata sandi. Distribusi lain mungkin memiliki utilitas sendiri untuk tugas yang sama. Jika tidak, maka Anda dapat langsung mengedit file di direktori /etc/grub.d dan membuat ulang grub.cfg .

Dalam file /etc/grub.d/10_linux , ubah variabel CLASS, tambahkan opsi --unrestricted hingga akhir, jika tidak ada di sana:

 CLASS="--class gnu-linux --class gnu --class os --unrestricted" 

Dalam file /etc/grub.d/40_custom tambahkan baris yang menentukan nama pengguna dan kata sandi yang diperlukan untuk mengedit baris perintah kernel:

 set superusers="root" password_pbkdf2 root grub.pbkdf2....... #    grub2-mkpasswd-pbkdf2 

Atau, jika fungsi seperti itu perlu dinonaktifkan sama sekali, berikut ini adalah baris seperti ini:

 set superusers="" 

Situasi 3 . Penyerang memiliki akses ke komputer yang disertakan, memungkinkan Anda untuk boot dari media yang tidak terpercaya. Ini bisa berupa akses fisik tanpa membuka kasing atau akses melalui IPMI. Tujuannya adalah akses root.

Ia dapat memuat GRUB-nya dari USB flash drive atau CD-ROM dan menambahkan init=/bin/sh ke parameter kernel Anda, seperti pada contoh sebelumnya. Karenanya, boot dari media mengerikan apa pun harus dilarang di BIOS. Dan juga melindungi perubahan pengaturan BIOS dengan kata sandi.

Situasi 4 . Penyerang memiliki akses fisik ke komputer yang disertakan, termasuk kemampuan untuk membuka kasing. Tujuannya adalah untuk mengetahui kunci atau mendapatkan akses root.

Secara umum, ini adalah situasi yang kalah. Serangan pada modul memori dengan mendinginkannya ( Serangan boot dingin ) belum dibatalkan. Secara teoritis (tidak memeriksa), Anda dapat memanfaatkan fakta bahwa disk SATA modern mendukung koneksi ulang panas. Ketika Anda me-restart komputer, lepaskan disk, ubah grub.cfg untuk init=/bin/sh , hubungkan kembali, biarkan sistem reboot. Ternyata (jika saya mengerti benar) akses root.

Tentang hal yang sama dapat dilakukan oleh karyawan yang tidak bertanggung jawab dari cloud hosting dengan membuat snapshot dari mesin virtual dengan modifikasi selanjutnya.

Masalah lainnya

Menyimpan kunci dalam memori selama reboot adalah sebuah olok-olok. Gunakan-setelah-bebas dalam bentuknya yang paling murni. Solusi yang lebih bersih adalah menggunakan kexec dan menambahkan kunci ke initramf yang dihasilkan secara dinamis. Ini juga melindungi dari mengganti parameter kernel . Ya, benar, jika kexec berfungsi. Distribusi modern membuat konfigurasi kexec terlalu rumit .

Di pusat data, dan terlebih lagi di cloud, daya tidak pernah hilang. Ternyata frasa kunci tidak lagi diperlukan? Memang, jika Anda yakin akan hal ini, Anda dapat menghapusnya. Ini akan berubah menjadi server yang berfungsi, kunci ke disk yang tidak diketahui siapa pun dan karena itu tidak akan memberikan, tetapi sistem yang dapat diperbarui menggunakan cara biasa. — sudo poweroff .

¹ /root/key — , cron.

? IPMI, . IPMI Java. .

? SSH . ! . , sudo reboot , ?

, . SSH , . , , .