Pembetulan: OpenVPN tidak dapat membaca nama pengguna Auth daripada input standard

could not read Auth username from stdin kelihatan seperti masalah pengesahan tetapi bukan. OpenVPN cuba meminta nama pengguna pada input standard, tidak menemui apa-apa yang boleh dibaca dan berhenti sebelum ia menghubungi pelayan. Akaun itu mungkin sah sepenuhnya; proses itu cuma tiada sesiapa untuk ditanya.

Sebab itu langkah berguna pertama ialah mengesahkan apa yang dibaca oleh klien, bukan mencuba semula sambungan atau menukar tetapan di sebelah pelayan. Lalui pemeriksaan di bawah mengikut urutan dan berhenti pada yang pertama gagal.

Baca ralat itu sebagai kegagalan input setempat

Apabila auth-user-pass muncul tanpa argumen fail, klien menjangka untuk bertanya. Dalam shell interaktif gesaan itu berfungsi kerana proses itu memiliki terminal. Di bawah systemd, tugas cron atau kontena, input standard biasanya kosong dan bacaan itu kembali serta-merta dengan ralat yang anda lihat.

Mesej itu juga menamakan medan yang gagal, nama pengguna atau kata laluan, yang menunjukkan sejauh mana bacaan itu pergi. Nama pengguna yang hilang bermaksud proses itu tidak dapat membaca apa-apa pun. Kata laluan yang hilang selepas nama pengguna berjaya bermaksud aliran input berakhir antara kedua-dua bacaan, yang lazim bagi fail yang separuh ditulis atau paip yang ditutup.

Sahkan pandangan klien itu sendiri sebelum menukar apa-apa lagi. Jalankannya di latar depan dengan konfigurasi dan pengguna yang sama, dan perhatikan sama ada gesaan itu muncul. Jika ia muncul dalam shell anda tetapi tidak di bawah pengurus perkhidmatan, perbezaannya ialah sumber input, bukan kelayakan. Perbandingan pantas fail unit dan persekitaran shell anda biasanya menunjukkan yang mana menyediakan terminal.

Berikan perkhidmatan sumber kelayakan yang disokong

Sumber tanpa pengawasan yang disokong ialah fail kelayakan yang dihantar sebagai argumen kepada auth-user-pass. Fail itu dibaca sebagai teks biasa: baris pertama ialah nama pengguna, baris kedua ialah kata laluan. Tuju kepadanya dengan laluan mutlak seperti /etc/openvpn/client/creds , supaya direktori kerja akaun perkhidmatan tidak boleh mengubah maksud arahan itu.

Kebenaran sama pentingnya dengan laluan. Fail itu mesti boleh dibaca oleh akaun yang menjalankan klien dan bukan oleh orang lain, dan ia patut dimiliki oleh akaun perkhidmatan atau root dengan kumpulan yang merangkumi perkhidmatan itu. Semak kebolehbacaan sebagai akaun itu, tanpa mencetak kandungannya.

Laluan relatif ialah mod kegagalan senyap. Profil mungkin berada dalam satu direktori manakala systemd memulakan proses di tempat lain, jadi fail yang diselesaikan dalam shell anda tidak diselesaikan untuk perkhidmatan itu. Pindahkan kelayakan ke lokasi tetap dan rujuknya secara mutlak. Kemudian mulakan perkhidmatan sekali dan sahkan laluan yang sama digunakan, bukannya mempercayai paparan penyunting profil.

Jika penggunaan memerlukan kod sekali sahaja atau cabaran interaktif lain, tentukan sama ada aliran kerja klien benar-benar menyokongnya tanpa pengawasan. Fail dengan kata laluan statik tidak boleh menjawab kod yang berputar, dan mencuba semula gesaan yang tidak dapat dijawab tidak menambah maklumat.

Mengapa script-security tidak akan membantu

script-security mengawal sama ada klien boleh menjalankan skrip dan berapa banyak yang boleh diserahkannya, termasuk sama ada kata laluan boleh diberikan kepada skrip melalui pemboleh ubah persekitaran. Ia tidak mengatakan apa-apa tentang dari mana nama pengguna dan kata laluan datang pada mulanya.

Menaikkannya ke tahap yang lebih tinggi ialah refleks biasa kerana mesej itu menyebut Auth, tetapi ia menukar kebenaran skrip dan bukan sumber input, dan ia meluaskan apa yang boleh dilaksanakan oleh klien. Jika skrip pembantu ialah sebahagian daripada reka bentuk, betulkan sumber input dahulu dan kekalkan tahap keselamatan pada nilai terendah yang diperlukan oleh penggunaan.

Antara muka pengurusan ialah alternatif yang sah. Frontend boleh menyambung kepadanya, menerima permintaan kelayakan dan menjawab dengan nama pengguna dan kata laluan, begitulah sesetengah GUI berfungsi. Jika anda menggunakannya, ikatkannya pada alamat setempat, lindunginya dengan fail kata laluan pengurusan dan hadkan siapa yang boleh menyambung, kerana ia saluran kawalan untuk klien.

Sahkan peringkat seterusnya selepas klien membaca fail itu

Sebaik sahaja klien boleh membaca kelayakan, kegagalan seterusnya ialah pertukaran sebenar dengan pelayan, dan mesejnya mempunyai makna yang berbeza. Kegagalan pengesahan pada peringkat itu bermaksud pelayan menolak akaun itu; respons cabaran bermaksud pelayan mahukan faktor lain. Anggapnya sebagai masalah baharu dan bukan masalah yang sama berulang.

Uji keseluruhan laluan seperti perkhidmatan itu akan menjalankannya: akaun sama, direktori kerja sama, persekitaran unit sama. Sambungan yang hanya berfungsi apabila dimulakan dari shell anda ialah tanda bahawa pemboleh ubah persekitaran atau terminal masih sebahagian daripada aliran itu.

Kemudian simpan rahsia di tempat yang sepatutnya. Kata laluan dalam argumen baris perintah muncul dalam jadual proses, dan kata laluan dalam output nyahpepijat berakhir dalam tiket. Gunakan fail terlindung atau antara muka pengurusan, kekalkan log pada tahap yang tidak mengulang kelayakan, dan tukar fail itu apabila sesiapa yang mempunyai akses pergi.

Senarai semak: laluan kelayakan mutlak, boleh dibaca sebagai akaun perkhidmatan, terminal tidak diperlukan, script-security dikekalkan pada minimumnya, antara muka pengurusan hanya jika ia terikat dan disahkan, dan respons pelayan yang terhasil dianggap sebagai peristiwa berasingan.