OpenVPN auth-user-pass: fail, stdin atau gesaan? Cara memilih

Tiga perkara menentukan sumber kelayakan yang patut digunakan: sama ada seseorang duduk di konsol, sama ada rahsia boleh hidup pada cakera, dan sama ada proses lain mesti menjawab gesaan. Jika silap pilih, klien melaporkan masalah stdin sedangkan kata laluan itu sah sepenuhnya, dan ini menghantar kebanyakan orang ke pelayan tanpa sebab. Pilih laluan dahulu; mesej ralat hanya bermakna apabila anda tahu laluan mana yang menghasilkannya.

Tiga syarat yang menentukannya

Gesaan konsol ialah satu-satunya laluan yang memerlukan manusia, jadi ia satu-satunya yang gagal secara senyap dalam unit systemd atau kontena. Jika seseorang memulakan klien dan menaip kata laluan, tiada fail terlibat dan tiada apa-apa sensitif mendarat pada cakera. Jika klien bermula semasa but, gesaan yang sama menjadi tergantung, dan tamat masa biasanya muncul sebagai kegagalan sambungan umum dan bukan ralat kelayakan.

Fail kelayakan ialah jawapan yang betul apabila proses bermula tanpa pengawasan dan rahsia boleh kekal pada cakera di bawah set kebenaran yang dikawal. Apabila rahsia tidak boleh ditulis langsung - dasar peti besi sahaja, token jangka pendek - anda memerlukan aliran yang boleh dibuka oleh klien, yang dalam praktiknya bermaksud penggantian proses atau pembantu yang menulis ke deskriptor fail. Antara muka pengurusan merangkumi kes keempat: pengawal yang sudah mengurus kitaran hayat terowong dan boleh menjawab soalan melalui soket.

• Manusia di konsol, tiada automasi: gesaan interaktif.
• Permulaan tanpa pengawasan, rahsia boleh disimpan: fail kelayakan dengan mod 0600.
• Permulaan tanpa pengawasan, rahsia tidak boleh disimpan: penggantian proses atau fd yang ditulis oleh ejen rahsia.
• Proses lain memiliki klien: antara muka pengurusan.

Apabila dua jawapan sesuai, pilih yang menyimpan rahsia di luar argv dan di luar sejarah shell. Kata laluan yang dihantar sebagai argumen program boleh dibaca oleh setiap pengguna tempatan melalui senarai proses, dan pendedahan itu sukar ditarik balik.

Apa yang sebenarnya dilakukan setiap laluan input

--auth-user-pass sendiri meminta nama pengguna dan kata laluan di konsol. Jika diberi nama fail, klien mengambil baris pertama sebagai nama pengguna dan baris kedua sebagai kata laluan; tiada apa yang menyokong petikan, komen atau sintaks kunci-nilai. Itulah keseluruhan format, jadi sesiapa yang mengeditnya dengan mengharapkan fail INI akan merosakkannya. Blok <auth-user-pass> sebaris menyimpan dua baris yang sama di dalam profil, yang menjadikan profil itu sendiri rahsia dan meletakkannya dalam kelas pengendalian yang sama seperti kunci peribadi.

Dua laluan lain ialah aliran dan soket. OpenVPN hanya memerlukan deskriptor fail yang boleh dibaca, jadi ia akan menerima penggantian proses, entri /dev/fd yang disokong paip atau nama fail yang sebenarnya FIFO. Antara muka pengurusan berbeza dari segi sifat: klien bertanya kepada proses penyelia untuk nilai-nilai itu dan bukan membacanya sendiri. Perbezaan itu penting semasa sambung semula: fail kelayakan, FIFO yang boleh ditulis semula oleh pembantu rahsia, dan antara muka pengurusan boleh membekalkan semula tanpa manusia; penggantian proses tidak boleh, kerana deskriptor itu habis pada bacaan pertama.

Fail itu mesti tepat dua baris

Dua mod kegagalan merangkumi kebanyakan fail kelayakan yang rosak. Editor Windows meninggalkan pengakhiran CRLF, pulangan pengangkutan menjadi sebahagian daripada kata laluan, dan pelayan menolak nilai yang kelihatan betul pada skrin. Baris kedua kosong - baris kosong di tempat kata laluan sepatutnya - meninggalkan klien dengan kata laluan kosong, yang ditolak pelayan walaupun nilai pada skrin kelihatan betul. Baris baru tambahan selepas kata laluan tidak berbahaya. Tulis fail itu daripada shell, bukan daripada editor, dan periksa baitnya:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Laluan sama pentingnya dengan kandungan. Laluan relatif diselesaikan terhadap direktori kerja proses, yang bagi perkhidmatan jarang menjadi direktori tempat anda menguji. Gunakan laluan mutlak, jadikan fail itu milik akaun yang menjalankan klien, dan kekalkan mod 0600 supaya kumpulan dan orang lain tidak dapat membacanya. Manual OpenVPN 2.6 menyenaraikan bentuk arahan yang diterima; semaknya sebelum anda mencipta bentuk ketiga.

Uji fail itu sebelum menyalahkan pelayan. Menjalankan openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 mencetak sama ada fail dibuka dan, kemudian, sama ada kelayakan diterima, yang memberitahu anda lapisan mana untuk diubah seterusnya.

Aliran, stdin dan ralat yang dihasilkannya

Menyalurkan kata laluan melalui paip ialah perkara pertama yang dicuba kebanyakan orang dan laluan dengan paling banyak kejutan. Penggantian proses berfungsi kerana klien hanya memerlukan deskriptor yang boleh dibaca: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Menghantar /dev/stdin hanya berfungsi apabila stdin masih terbuka dan boleh dibaca pada saat klien bertanya, yang tidak benar dalam saluran paip yang sudah memakannya.

ERROR: could not read Auth username from stdin mempunyai dua punca berbeza. Pada sesetengah klien 2.3.x mesej itu datang daripada kecacatan pengendalian stdin yang dibetulkan oleh keluaran 2.3 kemudian, jadi klien setua itu hanya bertambah baik dengan menaik taraf. Pada klien semasa, perkataan yang sama bermaksud klien meminta input konsol dan stdin bukan terminal - tepat keadaan dalam unit systemd, tugas cron atau kontena yang dimulakan tanpa -t.

auth-nocache menambah gelung ketiga yang kelihatan seperti kata laluan rosak. Ia membuang kelayakan daripada memori selepas digunakan, jadi sambungan semula yang dicetuskan oleh perubahan rangkaian tidak mempunyai apa-apa untuk dimainkan semula dan gesaan itu kembali. Itulah arahan yang berfungsi seperti direka. auth-nocache menukar apa yang disimpan klien dalam memori, bukan apa yang pelayan atau pembekal identiti fikirkan tentang akaun, jadi seluruh pembetulan ialah membekalkan semula fail yang sama, dibaca semula semasa mula semula - dan untuk sambungan terurus bekalan itu harus datang daripada stor rahsia yang diluluskan, bukan kata laluan dalam skrip.

Antara muka pengurusan apabila proses lain memiliki gesaan

Pengawal yang sudah menyelia terowong juga boleh menjawab soalannya. Mulakan klien dengan --management 127.0.0.1 7505, baca baris keadaan, dan perhatikan >PASSWORD:Need 'Auth' username/password. Pengawal menjawab dengan username "Auth" alice diikuti password "Auth" ... pada baris arahan berasingan. Token 'Auth' mengulang pengecam daripada permintaan dan mesti sepadan, jika tidak jawapan itu diabaikan dan klien menunggu.

Kosnya ialah mesin keadaan yang kini anda miliki: susunan sambungan, mula semula klien, dan soket tempatan yang tidak boleh dicapai oleh pengguna lain pada hos. Apa yang anda beli ialah kelayakan yang dibekalkan pada masa jalan, tanpa fail pada cakera dan tanpa gesaan yang boleh tergantung. Jika tiada apa-apa lagi dalam tindanan anda sudah bercakap protokol ini, laluan ini menambah komponen untuk diselenggara.

Kegagalan yang kelihatan seperti masalah kelayakan

Genggaman tangan TLS yang tidak pernah selesai, atau VERIFY ERROR: depth=0, error=certificate signature failure, ialah masalah kepercayaan dan berlaku sebelum sebarang nama pengguna dibaca. Klien proto tcp yang dihalakan ke pendengar UDP gagal di tempat yang sama: paket tidak pernah sampai ke peringkat pengesahan, jadi setiap kata laluan kelihatan salah melalui perkaitan. Kekalkan pengesahan sijil dihidupkan sebelum kelayakan dihantar; gesaan yang biasa tidak memberitahu apa-apa tentang siapa yang menerima kata laluan. Periksa rantaian sijil, nama umum dan pengangkutan sebelum menyentuh kelayakan.

Pepijat shell dalam skrip yang memasang profil ialah jejak palsu yang lain. Ruang yang hilang di dalam [ ! -f "$file" ] menghasilkan command not found, skrip berhenti awal, profil tidak pernah dibina semula, dan klien bermula dengan yang sebelumnya. Ralat itu milik shell, bukan pengesahan, dan berapa kali pun anda menaip semula kata laluan, ia tidak akan hilang.

Bukan setiap gesaan dalam aliran ini ialah kelayakan ini. Frasa laluan kunci peribadi, log masuk proksi HTTP dan kata laluan perkhidmatan ialah tiga rahsia berbeza yang diminta pada fasa berbeza, dan frasa laluan kunci biasanya dikendalikan oleh klien atau ejen dan bukan auth-user-pass. Jika gesaan muncul sebelum sesi TLS berdiri, anda menjawab soalan yang salah dan tiada set semula akaun akan membantu. Setelah gesaan yang salah dikecualikan, pemeriksaan yang tinggal bermula dari lapisan paling awal:

• Baca ralat protokol pertama, bukan baris kelayakan terakhir: TLS, kemudian pengesahan, kemudian push.
• Sahkan fail itu dua baris, tiada pulangan pengangkutan dan dirujuk dengan laluan mutlak.
• Sahkan profil dan baris arahan tidak bercanggah tentang arahan itu.
• Pisahkan "kelayakan diterima" daripada "trafik mengalir" - penghalaan dan DNS ialah lapisan kemudian.

Apabila klien mencapai fasa push, berhenti melihat kelayakan dan mula membaca laluan dan pelayan DNS yang dihantar oleh pelayan. Itu masalah seterusnya, dan ia tiada kaitan dengan kata laluan yang baru anda betulkan.