OpenVPN PAM: argumen login adalah nama layanan, bukan nama pengguna

Seorang pengguna ditambahkan di server, kata sandi diketik dengan benar, tetapi koneksi tetap berakhir dengan AUTH_FAILED. Baris plugin biasanya menjelaskan sebabnya: kata setelah jalur plugin adalah nama layanan PAM, dan itu menentukan tumpukan modul mana yang menjawab pertanyaan. Itu bukan nama pengguna, dan bukan penunjuk ke berkas kata sandi yang OpenVPN baca sendiri.

Apa yang dipilih kata kedua

Baris konfigurasi mengambil jalur plugin dan satu argumen:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Argumen itu diteruskan ke pustaka PAM sebagai nama layanan, sehingga tumpukan di /etc/pam.d/openvpn yang dijalankan. Tulis login di sana dan Anda malah mendapatkan kebijakan login interaktif, dengan modul apa pun yang kebijakan itu sertakan pada distribusi Anda.

Gunakan jalur plugin yang disediakan paket terpasang, bukan jalur yang disalin dari host lain. Nama berkas dan direktorinya berbeda antar distribusi, dan jalur yang salah gagal saat mulai dengan galat pemuatan plugin, bukan saat autentikasi.

Dari mana tumpukan itu sebenarnya membaca akun

PAM adalah pengirim. Berkas layanan mencantumkan modul secara berurutan, dan modul pertama yang bisa menjawab menentukan hasilnya. Tumpukan yang memanggil pam_unix membaca akun lokal; tumpukan yang memanggil modul LDAP atau RADIUS mengirim kredensial ke tempat yang sama sekali lain.

Baca berkas tempat nama layanan diselesaikan, termasuk apa pun yang disertakannya:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

Jika tumpukan mendelegasikan ke direktori, menambahkan akun lokal tidak mengubah apa pun. Jika tumpukan membaca akun lokal, membuat pengguna di direktori juga tidak mengubah apa pun. Akun harus ada di tempat tumpukan melihat, dan itulah seluruh diagnosis pada sebagian besar laporan ini.

Satu percobaan, dua log

Korelasikan satu koneksi yang gagal di kedua sisi. Log OpenVPN menunjukkan hasil plugin dan penolakan klien; log autentikasi sistem menunjukkan modul mana yang berjalan dan apa yang diputuskannya. Membaca keduanya dalam jendela waktu yang sama itulah yang memisahkan berkas layanan yang hilang dari batas waktu backend. Celah pada log autentikasi berarti tumpukan tidak pernah tersentuh sama sekali.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Uji layanan itu langsung dengan utilitas yang berbicara PAM, supaya Anda tidak menelusuri VPN dan tumpukan sekaligus. Uji langsung yang berhasil dengan nama layanan dan akun yang sama mempersempit masalah ke cara daemon meneruskan kredensial, bukan ke akunnya.

pamtester openvpn alice authenticate

Jika uji langsung gagal dengan kredensial yang sama yang berhasil di konsol, tumpukan tidak membaca sumber akun yang Anda anggap. Jika berhasil, lihat percakapan yang dijalankan plugin dan apa yang benar-benar dikirim klien. Jalankan sekali juga dengan kata sandi yang sengaja salah, agar Anda melihat perbedaan antara penolakan dan galat modul. Kedua hasil itu tampak identik di log VPN dan sangat berbeda di sini.

Layanan khusus lebih baik daripada menyunting login

Beri VPN berkas layanan sendiri ketika kebutuhannya berbeda dari login interaktif, yang biasanya memang demikian. Menyunting login atau common-auth mengubah kebijakan bagi setiap program yang menyertakannya, dan orang berikutnya yang menelusuri masalah login tak terkait akan mewarisi perubahan Anda.

Salin modul yang Anda butuhkan ke berkas layanan kecil, jaga urutannya tetap eksplisit, dan catat siapa pemiliknya. Berkas itulah yang perlu diperiksa ketika pengaturan ulang kata sandi tampaknya tidak berpengaruh.

Apa yang dikirim klien, dan apa yang tidak

Klien memasok nama pengguna dan kata sandi melalui permintaan atau berkas yang didukungnya. Plugin server meneruskan nilai itu ke percakapan PAM; plugin tidak membacanya dari konfigurasi server. Baris di sisi server yang tampak mendefinisikan kata sandi tidak melakukan itu, dan tidak ada penyuntingan profil yang akan membuat akun.

Nama pengguna dan kata sandi dapat hidup berdampingan dengan sertifikat klien, dan mengaktifkan PAM bukan alasan untuk berhenti memverifikasi sertifikat. Pertahankan lapisan yang dimaksudkan penerapan itu dan perbaiki hanya sumber akunnya.

Penerimaan bersifat dua arah: akun yang dituju berhasil, dan akun yang seharusnya ditolak tetap gagal. Berkas README plugin auth-pam mendokumentasikan argumen layanan dan backend yang dapat dilayaninya, dan di situlah tempat mengonfirmasi susunan yang hendak Anda bangun.