OpenVPN auth-user-pass: file, stdin, atau prompt? Cara memilih

Tiga hal menentukan sumber kredensial yang harus Anda pakai: apakah ada orang di konsol, apakah rahasia boleh hidup di disk, dan apakah proses lain harus menjawab prompt. Salah memilih dan klien melaporkan masalah stdin padahal kata sandinya sepenuhnya valid, yang membuat kebanyakan orang pergi ke server tanpa alasan. Pilih jalurnya lebih dulu; pesan kesalahan baru masuk akal setelah Anda tahu jalur mana yang menghasilkannya.

Tiga kondisi yang menentukan

Prompt konsol adalah satu-satunya jalur yang membutuhkan manusia, jadi satu-satunya yang gagal diam-diam di unit systemd atau kontainer. Jika seseorang menjalankan klien dan mengetik kata sandi, tidak ada file yang terlibat dan tidak ada hal sensitif yang mendarat di disk. Jika klien dijalankan saat boot, prompt yang sama berubah menjadi macet, dan timeout biasanya muncul sebagai kegagalan koneksi umum alih-alih kesalahan kredensial.

File kredensial adalah jawaban yang tepat ketika proses dijalankan tanpa pengawasan dan rahasia boleh bertahan di disk di bawah kumpulan izin yang terkendali. Ketika rahasia tidak boleh ditulis sama sekali - kebijakan hanya brankas, token berumur pendek - Anda perlu aliran yang bisa dibuka klien, yang dalam praktik berarti substitusi proses atau pembantu yang menulis ke deskriptor file. Antarmuka manajemen mencakup kasus keempat: pengendali yang sudah mengelola siklus hidup terowongan dan dapat menjawab pertanyaan lewat socket.

• Manusia di konsol, tanpa otomatisasi: prompt interaktif.
• Mulai tanpa pengawasan, rahasia boleh disimpan: file kredensial dengan mode 0600.
• Mulai tanpa pengawasan, rahasia tidak boleh disimpan: substitusi proses atau fd yang ditulis agen rahasia.
• Proses lain memiliki klien: antarmuka manajemen.

Ketika dua jawaban cocok, pilih yang menjaga rahasia di luar argv dan di luar riwayat shell. Kata sandi yang diteruskan sebagai argumen program dapat dibaca setiap pengguna lokal melalui daftar proses, dan paparan itu sulit dibatalkan.

Apa yang sebenarnya dilakukan setiap jalur input

--auth-user-pass sendiri meminta nama pengguna dan kata sandi di konsol. Jika diberi nama file, klien mengambil baris pertama sebagai nama pengguna dan baris kedua sebagai kata sandi; tidak ada yang mendukung tanda kutip, komentar, atau sintaks kunci-nilai. Itulah seluruh formatnya, jadi siapa pun yang mengeditnya dengan mengharapkan file INI akan merusaknya. Blok <auth-user-pass> sebaris menyimpan dua baris yang sama di dalam profil, yang membuat profil itu sendiri menjadi rahasia dan menempatkannya di kelas penanganan yang sama dengan kunci privat.

Dua jalur lainnya adalah aliran dan socket. OpenVPN hanya membutuhkan deskriptor file yang dapat dibaca, jadi ia akan menerima substitusi proses, entri /dev/fd yang didukung pipa, atau nama file yang sebenarnya adalah FIFO. Antarmuka manajemen berbeda jenisnya: klien meminta nilai kepada proses pengawas alih-alih membacanya sendiri. Perbedaan itu penting saat menyambung ulang: file kredensial, FIFO yang dapat ditulisi lagi oleh pembantu rahasia, dan antarmuka manajemen dapat memasok ulang tanpa manusia; substitusi proses tidak bisa, karena deskriptornya habis pada pembacaan pertama.

File harus tepat dua baris

Dua mode kegagalan mencakup sebagian besar file kredensial yang rusak. Editor Windows meninggalkan akhiran CRLF, carriage return menjadi bagian dari kata sandi, dan server menolak nilai yang tampak benar di layar. Baris kedua yang kosong - baris kosong di tempat kata sandi seharusnya berada - membuat klien dengan kata sandi kosong, yang ditolak server meskipun nilai di layar tampak benar. Baris baru tambahan setelah kata sandi tidak berbahaya. Tulis file dari shell, bukan dari editor, dan periksa byte-nya:

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

Jalur sama pentingnya dengan isi. Jalur relatif diselesaikan terhadap direktori kerja proses, yang untuk layanan jarang merupakan direktori tempat Anda menguji. Gunakan jalur absolut, jadikan file milik akun yang menjalankan klien, dan pertahankan mode 0600 agar grup dan orang lain tidak dapat membacanya. Manual OpenVPN 2.6 mencantumkan bentuk direktif yang diterima; periksa sebelum Anda menciptakan bentuk ketiga.

Uji file sebelum menyalahkan server. Menjalankan openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 mencetak apakah file dibuka dan, nanti, apakah kredensial diterima, yang memberi tahu Anda lapisan mana yang harus diubah berikutnya.

Aliran, stdin, dan kesalahan yang dihasilkannya

Menyalurkan kata sandi lewat pipa adalah hal pertama yang dicoba kebanyakan orang dan jalur dengan kejutan terbanyak. Substitusi proses berhasil karena klien hanya membutuhkan deskriptor yang dapat dibaca: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Meneruskan /dev/stdin hanya berhasil ketika stdin masih terbuka dan dapat dibaca pada saat klien bertanya, yang tidak benar dalam pipa yang sudah mengonsumsinya.

ERROR: could not read Auth username from stdin memiliki dua penyebab berbeda. Pada sebagian klien 2.3.x pesan itu berasal dari cacat penanganan stdin yang diperbaiki rilis 2.3 berikutnya, jadi klien setua itu hanya membaik dengan meningkatkan versi. Pada klien terkini kata-kata yang sama berarti klien meminta input konsol dan stdin bukan terminal - persis situasi di unit systemd, tugas cron, atau kontainer yang dijalankan tanpa -t.

auth-nocache menambahkan putaran ketiga yang tampak seperti kata sandi rusak. Direktif ini membuang kredensial dari memori setelah dipakai, sehingga penyambungan ulang yang dipicu perubahan jaringan tidak punya apa pun untuk diputar ulang dan prompt kembali muncul. Itulah direktif yang bekerja sesuai rancangan. auth-nocache mengubah apa yang disimpan klien di memori, bukan apa yang dipikirkan server atau penyedia identitas tentang akun, jadi seluruh perbaikannya adalah memasok ulang file yang sama, dibaca ulang saat restart - dan untuk koneksi terkelola pasokan itu harus datang dari penyimpanan rahasia yang disetujui, bukan kata sandi dalam skrip.

Antarmuka manajemen ketika proses lain memiliki prompt

Pengendali yang sudah mengawasi terowongan juga dapat menjawab pertanyaannya. Jalankan klien dengan --management 127.0.0.1 7505, baca baris status, dan pantau >PASSWORD:Need 'Auth' username/password. Pengendali menjawab dengan username "Auth" alice diikuti password "Auth" ... pada baris perintah terpisah. Token 'Auth' menggemakan pengenal dari permintaan dan harus cocok, jika tidak jawabannya diabaikan dan klien menunggu.

Harganya adalah mesin status yang kini Anda miliki: urutan koneksi, restart klien, dan socket lokal yang tidak boleh dijangkau pengguna lain di host. Yang Anda beli adalah kredensial yang dipasok saat runtime, tanpa file di disk dan tanpa prompt yang bisa macet. Jika tidak ada hal lain di tumpukan Anda yang sudah berbicara protokol ini, jalur ini menambah komponen yang harus dipelihara.

Kegagalan yang tampak seperti masalah kredensial

Jabat tangan TLS yang tidak pernah selesai, atau VERIFY ERROR: depth=0, error=certificate signature failure, adalah masalah kepercayaan dan terjadi sebelum nama pengguna apa pun dibaca. Klien proto tcp yang diarahkan ke pendengar UDP gagal di titik yang sama: paket tidak pernah mencapai tahap autentikasi, jadi setiap kata sandi tampak salah karena asosiasi. Biarkan verifikasi sertifikat menyala sebelum kredensial dikirim; prompt yang familier tidak mengatakan apa pun tentang siapa yang menerima kata sandi. Periksa rantai sertifikat, nama umum, dan transportasi sebelum menyentuh kredensial.

Bug shell dalam skrip yang merakit profil adalah jejak palsu lainnya. Spasi yang hilang di dalam [ ! -f "$file" ] menghasilkan command not found, skrip berhenti lebih awal, profil tidak pernah dibangun ulang, dan klien dijalankan dengan profil sebelumnya. Kesalahan itu milik shell, bukan autentikasi, dan sebanyak apa pun Anda mengetik ulang kata sandi, itu tidak akan hilang.

Tidak setiap prompt dalam alur ini adalah kredensial ini. Frasa sandi kunci privat, login proxy HTTP, dan kata sandi layanan adalah tiga rahasia berbeda yang diminta pada fase berbeda, dan frasa sandi kunci biasanya ditangani klien atau agen alih-alih auth-user-pass. Jika prompt muncul sebelum sesi TLS berdiri, Anda menjawab pertanyaan yang salah dan tidak ada reset akun yang membantu. Setelah prompt yang salah disingkirkan, pemeriksaan yang tersisa dimulai dari lapisan paling awal:

• Baca kesalahan protokol pertama, bukan baris kredensial terakhir: TLS, lalu autentikasi, lalu push.
• Pastikan file terdiri dari dua baris, tidak mengandung carriage return, dan dirujuk dengan jalur absolut.
• Pastikan profil dan baris perintah tidak berselisih tentang direktif.
• Pisahkan "kredensial diterima" dari "lalu lintas mengalir" - perutean dan DNS adalah lapisan berikutnya.

Ketika klien mencapai fase push, berhenti melihat kredensial dan mulai membaca rute serta server DNS yang dikirim server. Itu masalah berikutnya, dan tidak ada hubungannya dengan kata sandi yang baru saja Anda perbaiki.