Cara membuka port di awal proses boot untuk membuka kunci LUKS melalui SSH

Saya memiliki server yang sepenuhnya terenkripsi yang menjalankan Debian 7 dan telah mengatur dropbear dan busybox untuk membuka kunci wadah LUKS melalui SSH (seperti yang dijelaskan dalam tutorial ini dan dalam jawaban U&L ini ).

Sayangnya, setiap kali saya mencoba dan SSH ke server (melalui LAN) saat reboot, saya mendapatkan kesalahan "Sambungan ditolak". Saya telah mencoba telnetdan nmapke port default (22) dan keduanya mengatakan port tersebut ditutup.

Server memiliki ufwaturan untuk menerima semua lalu lintas dari LAN:

Anywhere         ALLOW       192.168.1.0/24

Saya telah mencoba mengubah port yang mendengarkan dropbear di dalam /etc/defaults/dropbeartetapi sshdan telnetmasih menolak koneksi ¹ .

Bagaimana saya bisa memastikan bahwa port terbuka pada tahap itu dalam proses boot sehingga saya dapat terhubung untuk membuka kunci wadah LUKS?

Menonaktifkan firewall tidak ada bedanya: nmapmenunjukkan semua port masih ditutup.

Perbarui 2/14

Saya menambahkan break=premountke baris kernel dan melihat-lihat initramfs. dropbeartelah dimulai, tetapi jaringan tidak sampai pada titik itu. Setelah keluar, jaringan muncul dan boot berlanjut sampai muncul prompt untuk membuka kunci perangkat LUKS.

Pada titik ini, jaringan sudah menyala, dan tuan rumah telah diberi alamat IP yang benar, tetapi port 22 masih ditutup.

Jalur IP yang /etc/initramfs-tools/intiramfs.confsaya gunakan adalah:

export IP=192.168.1.200::192.168.1.1:255.255.255.0::eth0:off

Konsisten dengan petunjuk di /usr/share/doc/cryptsetup/README.remote.gzSaya telah mencoba menambahkan opsi perangkat saja, tetapi itu tidak cukup untuk membawa jaringan dan mendapatkan sewa dhcp.

Perbarui 11/10/14

Jawaban Karl adalah apa yang diperlukan: pengaturan /etc/initramfs-tools/conf.d/cryptrootadalah kuncinya:

target=md1_crypt,source=UUID=8570d12k-ccha-4985-s09f-e43dhed9fa2a

Panduan ini juga terbukti lebih mutakhir dan relevan (dan berhasil).

ssh networking luks

— jasonwryan
sumber

WOW! Saya benar-benar tidak tahu Anda bisa membuka kunci LUKS yang sepenuhnya terkunci. Jelas saya tidak bisa menjawab pertanyaan Anda w / kepastian tapi saya kira sshd belum dimulai. Di mesin saya, sshd mulai nanti dalam proses.

— emory

Apakah Anda memiliki akses konsol ke mesin saat berada di lingkungan busybox? Bisakah Anda memverifikasi bahwa dropbear benar-benar berjalan (via ps) dan mendengarkan pada port yang Anda harapkan (via netstat)?

— larsks

larsks - tidak, karena di konsol prompt menunggu frasa sandi dimasukkan, dan beralih ke TTY lain hanya berarti layar kosong (jika saya mengerti Anda dengan benar).

— jasonwryan

Bisakah Anda (sementara) menghapus enkripsi LUKS dan memverifikasi bahwa drop bear benar-benar berjalan?

— emory

Sudahkah Anda mencoba menggunakan salah satu break=Xparameter boot untuk mendapatkan initramfsshell awal ? Setiap kali saya men-debug kesengsaraan enkripsi sistem file, saya menggunakan break=premount. Anda dapat memeriksa apa situasinya, menyelesaikannya, dan melanjutkan booting.

— Alexios

Jawaban:

Saya mendapatkan masalah yang sama beberapa minggu yang lalu (Debian Wheezy 7.6) dan setelah beberapa hari pemecahan masalah saya menemukan bahwa ada file konfigurasi yang hilang yang mencegah skrip cryptroot di init-top untuk berjalan dengan benar, maka itu tidak berhenti untuk menanyakan kata sandi melalui ssh, membunuh dropbear di akhir urutan (init-bottom).

File config dipanggil cryptrootdan seharusnya berada di bawah. /etc/initramfs-tools/conf.d/ Jika saya tidak salah, file config seharusnya dibuat secara otomatis saat instalasi (saya hanya membaca satu tutorial tentang file config itu) tetapi entah bagaimana tidak (diuji di server fisik dan di VM, OS dan versi yang sama)

Butuh beberapa upaya untuk mengkonfigurasinya dengan benar, karena saya tidak dapat menemukan sintaks yang tepat pada waktu itu. File konfigurasi cryptroot saya adalah sebagai berikut:

target=crypt-root,source=/dev/vg0/root,lvm=root

Setelah dibuat, file konfigurasi baru saja memperbarui initramfs dan coba lagi:

update-initramfs -u

— Karl
sumber

Anda seorang LEGENDA! Terima kasih: Saya telah berjuang dengan ini selama berabad-abad dan telah cukup banyak menyerah untuk menyelesaikannya. cryptrootSintaks saya berbeda dengan Anda, tetapi jawaban Anda cukup untuk mengarahkan saya ke arah yang benar. Saya berhutang budi padamu.

— jasonwryan

Saya senang Anda akhirnya berhasil. Saya melihat pertanyaan Anda ketika saya sedang menyelidiki masalah saya dan saya pikir saya harus memposting bagaimana saya menyelesaikannya setelah saya menjalankannya.

— Karl

Baris subjek salah. Masalahnya bukan port tertutup, ini port yang tidak terikat. SSHd belum mulai; itulah alasan Anda tidak dapat terhubung ke sana.

— poige
sumber

@camh, apakah ada aturan tentang itu?

— poige

Saya lebih fokus pada kalimat pertama, yaitu editorial. Sisanya agak singkat untuk menjadi jawaban yang baik, tapi saya kira masih merupakan jawaban. Saya akan menghapus komentar saya.

— camh

@camh, begitu ...

— poige

Saya tidak menggunakan sshd: sebagai pertanyaan menyatakan, saya mencoba untuk terhubung ke instance dropbear yang berjalan pada port 22 secara default.

— jasonwryan

@jasonwryan, itu tidak memainkan peran apa sebenarnya layanan TCP yang Anda coba gunakan, yang penting adalah itu tidak dimulai.

— poige

Dropbear (ssh server) seharusnya dimulai sangat awal selama fase boot - lebih awal dari urutan init(rcN.d) dan skrip init firewall; bahkan lebih awal dari / sudah terpasang (itu dienkripsi juga, kan?). Begitulah initramfs, pre- / userland dimuat untuk kernel oleh boot loader. Gambar (re) dihasilkan oleh update-initramfs -udari konten /etc/initramfs-tools/, termasuk konfigurasi dropbear di /etc/initramfs-tools/etc/dropbear/. Untuk bermain dengan konfigurasi dropbear, mainkan dengan yang itu.

Jadi, beberapa poin untuk diperiksa:

dropbear tidak dimulai: itu belum dicolokkan ke urutan initramfs dengan baik;
firewall default menolak semua.

— yrk
sumber

Terima kasih yarek: Saya pikir Anda benar - Saya telah memperbarui pertanyaan saya dengan bug debian (dan perbaikan yang tidak berhasil). Saya juga mencoba menonaktifkan firewall.

— jasonwryan