auth-nocache dengan fail kelayakan: membantu atau memudaratkan?

OpenVPN mencetak amaran semasa permulaan yang mencadangkan auth-nocache, dan tindak balas yang menggoda ialah menambah pilihan itu dan melihat baris itu hilang. Nasihat itu menganggap log masuk interaktif. Sebaik sahaja nama pengguna dan kata laluan tinggal dalam fail, perbandingan berubah: pilihan itu berhenti melindungi salinan tahan lama, dan pada klien yang melepaskan keistimewaan ia boleh memecahkan rundingan semula kemudian. Dua model penyimpanan wajar diasingkan sebelum anda mengedit profil.

Dua cara menjawab permintaan kelayakan

Model pertama ialah manusia yang menaip kelayakan dalam terminal, atau antara muka pengurusan yang menyimpannya untuk sesi itu. OpenVPN menyimpan salinan itu supaya dapat menjawab rundingan semula seterusnya tanpa bertanya lagi, dan itulah tepatnya yang dimaksudkan oleh amaran itu. Tiada apa-apa pada cakera terlibat, jadi satu-satunya perkara yang perlu dilindungi ialah proses yang memegang nilai itu. Tutup klien dan salinan itu hilang bersamanya.

Model kedua ialah auth-user-pass yang menunjuk ke fail, di mana fail itu ialah stor dan klien membacanya apabila nilai diperlukan. Pendedahan yang penting di sini bukan memori proses tetapi kebenaran dan pemilikan fail itu. Amaran permulaan datang daripada arahan dalam konfigurasi, bukan daripada pemeriksaan cara anda membekalkan kata laluan, jadi ia muncul dalam kedua-dua model dan tidak menunjuk kepada mana-mana.

Selebihnya perbandingan ini mengikut pembahagian itu: pengendalian memori untuk satu model, pengendalian fail dan identiti proses untuk yang lain.

Apa yang sebenarnya dibuang oleh auth-nocache

Dengan log masuk interaktif, --auth-nocache mengalihkan salinan tersimpan daripada memori selepas ia digunakan. Kosnya ialah permintaan baharu pada setiap selang rundingan semula, kerana pusingan seterusnya tidak boleh menggunakan semula apa yang telah dibuang.

Dengan log masuk berasaskan fail klien boleh membaca fail itu sekali lagi, jadi pembuangan itu kebanyakannya tidak kelihatan. Ia menjadi kelihatan di satu tempat yang orang tidak jangkakan: selepas daemon melepaskan keistimewaan, jika fail kelayakan tidak boleh dibaca oleh akaun yang kini menjalankannya.

Tambahkan pilihan itu kerana anda memahami pertukaran itu, bukan kerana amaran muncul. Pilihan yang ditambah untuk menjadikan log lebih senyap ialah pilihan yang kesannya tidak diukur oleh sesiapa.

Di mana laluan berasaskan fail pecah

Klien yang bermula sebagai root untuk membuka peranti terowong dan kemudian bertukar kepada user dan group membaca fail kelayakan dua kali: sekali sebelum pertukaran, sekali pada rundingan semula yang menyusul. Jika fail itu dalam mod 600 dan dimiliki root, bacaan kedua gagal, dan kegagalan itu muncul sejam kemudian sebagai ralat pengesahan yang kelihatan seperti masalah pelayan. Periksa log klien di sekitar selang rundingan semula, kemudian periksa akaun dan fail itu bersama-sama.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Kedua-dua baris itu penting. Yang pertama memberitahu anda siapa yang boleh membaca fail itu, yang kedua memberitahu anda siapa daemon yang benar-benar berjalan, dan percanggahan antara keduanya menjelaskan kegagalan yang tidak akan dibaiki oleh penulisan semula kata laluan.

Pembaikan praktikal tidak glamor: pindahkan fail itu ke direktori dan pemilik yang boleh dibaca oleh akaun daemon, atau kekalkan bacaan istimewa dan sahkan bahawa klien anda hanya membaca sekali. Jangan selesaikannya dengan menjadikan fail itu boleh dibaca oleh semua orang.

Kes yang benar-benar mahukan pilihan itu

Log masuk yang membawa kod sekali guna mahukan auth-nocache atas sebab yang berbeza. Kod sekali guna habis digunakan oleh pengesahan pertama, jadi salinan dalam cache tidak berguna pada rundingan semula seterusnya dan nilai lapuk malah boleh dimainkan semula.

Itu soalan tentang jenis kelayakan, bukan tentang tempat ia disimpan. Kata laluan statik dalam fail terlindung mempunyai profil yang bertentangan: ia mesti boleh dibaca pada setiap rundingan semula, dan perlindungan yang anda perlukan ada pada fail itu.

Asingkan kedua-dua sebab itu dalam ulasan profil, jika tidak pentadbir seterusnya akan menganggap pilihan itu ada atas sebab yang dia sendiri akan pilih.

Perbandingan dalam satu keputusan

Pilih model interaktif apabila ada orang hadir dan kesegaran penting, dan terima permintaan berulang sebagai kosnya. Pilih model fail apabila klien berjalan tanpa pengawasan, dan belanjakan usaha pada pemilikan, mod dan pelepasan keistimewaan.

Tiada model menjadikan kata laluan tersimpan selamat dengan sendirinya, dan tiada yang menjadikan amaran permulaan bermakna.

Jika amaran itu satu-satunya sebab anda membuka profil, catat keputusan itu dan bukan pilihan tanpa penjelasan: kelayakan datang daripada fail yang boleh dibaca oleh akaun daemon, rundingan semula telah dilihat berjaya, dan bahagian tentang rundingan semula dalam manual OpenVPN 2.6 telah dibaca sebelum selangnya diubah. Nota itu bertahan lebih lama daripada mana-mana bendera tunggal.