Perbaikan: OpenVPN tidak dapat membaca nama pengguna Auth dari masukan standar

could not read Auth username from stdin terlihat seperti masalah autentikasi tetapi bukan. OpenVPN mencoba meminta nama pengguna pada masukan standar, tidak menemukan apa pun yang dapat dibaca, dan berhenti sebelum pernah menghubungi server. Akun bisa sepenuhnya valid; prosesnya hanya tidak punya siapa pun untuk ditanya.

Karena itu langkah bermanfaat pertama adalah memastikan apa yang dibaca klien, bukan mencoba ulang koneksi atau mengubah pengaturan di sisi server. Jalani pemeriksaan di bawah ini secara berurutan dan berhenti pada yang pertama gagal.

Baca galat sebagai kegagalan masukan lokal

Ketika auth-user-pass muncul tanpa argumen berkas, klien mengharapkan pertanyaan. Di shell interaktif pertanyaan itu bekerja karena proses memiliki terminal. Di bawah systemd, tugas cron, atau kontainer, masukan standar biasanya kosong, dan pembacaan langsung kembali dengan galat yang Anda lihat.

Pesan itu juga menyebut bidang yang gagal, nama pengguna atau kata sandi, yang menunjukkan seberapa jauh pembacaan berlangsung. Nama pengguna yang hilang berarti proses sama sekali tidak dapat membaca apa pun. Kata sandi yang hilang setelah nama pengguna berhasil berarti aliran masukan berakhir di antara kedua pembacaan, yang khas untuk berkas yang baru separuh ditulis atau pipa yang tertutup.

Pastikan pandangan klien itu sendiri sebelum mengubah hal lain. Jalankan di latar depan dengan konfigurasi dan pengguna yang sama, dan perhatikan apakah pertanyaan muncul. Jika muncul di shell Anda tetapi tidak di bawah manajer layanan, perbedaannya ada pada sumber masukan, bukan kredensial. Perbandingan cepat berkas unit dan lingkungan shell Anda biasanya menunjukkan mana yang menyediakan terminal.

Beri layanan sumber kredensial yang didukung

Sumber tanpa pengawasan yang didukung adalah berkas kredensial yang diteruskan sebagai argumen ke auth-user-pass. Berkas dibaca sebagai teks biasa: baris pertama adalah nama pengguna, baris kedua adalah kata sandi. Tunjuk dengan jalur absolut seperti /etc/openvpn/client/creds , agar direktori kerja akun layanan tidak dapat mengubah makna direktif.

Izin sama pentingnya dengan jalur. Berkas harus dapat dibaca oleh akun yang menjalankan klien dan bukan oleh semua orang, dan sebaiknya dimiliki oleh akun layanan atau root dengan grup yang mencakup layanan. Periksa keterbacaan sebagai akun itu, tanpa mencetak isinya.

Jalur relatif adalah mode kegagalan senyap. Profil bisa berada di satu direktori sementara systemd memulai proses di tempat lain, sehingga berkas yang terurai di shell Anda tidak terurai bagi layanan. Pindahkan kredensial ke lokasi tetap dan rujuk secara absolut. Lalu jalankan layanan sekali dan pastikan jalur yang sama digunakan, bukan mempercayai tampilan penyunting profil.

Jika penyebaran memerlukan kode sekali pakai atau tantangan interaktif lain, putuskan apakah alur kerja klien benar-benar mendukungnya tanpa pengawasan. Berkas dengan kata sandi statis tidak dapat menjawab kode yang berputar, dan mencoba ulang pertanyaan yang tidak dapat dijawab tidak menambah informasi.

Mengapa script-security tidak akan membantu

script-security mengatur apakah klien boleh menjalankan skrip dan berapa banyak yang boleh diteruskan kepadanya, termasuk apakah kata sandi dapat diberikan ke skrip melalui variabel lingkungan. Itu tidak mengatakan apa pun tentang dari mana nama pengguna dan kata sandi berasal.

Menaikkannya ke tingkat yang lebih tinggi adalah refleks umum karena pesan menyebut Auth, tetapi itu mengubah izin skrip, bukan sumber masukan, dan memperluas apa yang boleh dijalankan klien. Jika skrip pembantu adalah bagian dari desain, perbaiki dulu sumber masukan dan pertahankan tingkat keamanan pada nilai terendah yang dibutuhkan penyebaran.

Antarmuka manajemen adalah alternatif yang sah. Frontend dapat terhubung ke sana, menerima permintaan kredensial, dan menjawab dengan nama pengguna dan kata sandi, begitulah sebagian GUI bekerja. Jika Anda memakainya, ikat ke alamat lokal, lindungi dengan berkas kata sandi manajemen, dan batasi siapa yang dapat terhubung, karena itu kanal kendali bagi klien.

Verifikasi tahap berikutnya setelah klien membaca berkas

Setelah klien dapat membaca kredensial, kegagalan berikutnya adalah pertukaran nyata dengan server, dan pesannya memiliki makna berbeda. Kegagalan autentikasi pada tahap itu berarti server menolak akun; respons tantangan berarti server menginginkan faktor lain. Perlakukan sebagai masalah baru, bukan masalah yang sama terulang.

Uji seluruh jalur seperti layanan akan menjalankannya: akun sama, direktori kerja sama, lingkungan unit sama. Koneksi yang hanya bekerja saat dimulai dari shell Anda adalah tanda bahwa variabel lingkungan atau terminal masih bagian dari alur.

Lalu simpan rahasia di tempat yang semestinya. Kata sandi dalam argumen baris perintah terlihat di tabel proses, dan kata sandi di keluaran debug berakhir di tiket. Gunakan berkas terlindungi atau antarmuka manajemen, jaga log pada tingkat yang tidak mengulang kredensial, dan putar berkasnya saat siapa pun yang memiliki akses pergi.

Daftar periksa: jalur kredensial absolut, dapat dibaca sebagai akun layanan, tidak perlu terminal, script-security dibiarkan pada minimumnya, antarmuka manajemen hanya jika terikat dan terautentikasi, dan respons server yang dihasilkan diperlakukan sebagai peristiwa terpisah.