OpenVPN PAM: argumen log masuk ialah nama perkhidmatan, bukan nama pengguna

Seorang pengguna ditambah pada pelayan, kata laluan ditaip dengan betul, tetapi sambungan masih berakhir dengan AUTH_FAILED. Baris pemalam biasanya menjelaskan sebabnya: perkataan selepas laluan pemalam ialah nama perkhidmatan PAM, dan ia menentukan tindanan modul mana yang menjawab soalan itu. Ia bukan nama pengguna, dan ia bukan penunjuk kepada fail kata laluan yang OpenVPN baca sendiri.

Apa yang dipilih oleh perkataan kedua

Baris konfigurasi mengambil laluan pemalam dan satu argumen:

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

Argumen itu dihantar kepada pustaka PAM sebagai nama perkhidmatan, yang menjadikan tindanan di /etc/pam.d/openvpn yang dijalankan. Tulis login di situ dan anda akan mendapat dasar log masuk interaktif sebaliknya, dengan modul apa pun yang dasar itu sertakan pada distribusi anda.

Gunakan laluan pemalam yang disediakan oleh pakej yang dipasang, bukan laluan yang disalin daripada hos lain. Nama fail dan direktori berbeza antara distribusi, dan laluan yang salah gagal semasa permulaan dengan ralat pemuatan pemalam, bukan semasa pengesahan.

Di mana tindanan sebenarnya membaca akaun

PAM ialah penghantar. Fail perkhidmatan menyenaraikan modul mengikut urutan, dan modul pertama yang boleh menjawab menentukan hasilnya. Tindanan yang memanggil pam_unix membaca akaun setempat; tindanan yang memanggil modul LDAP atau RADIUS menghantar kelayakan ke tempat yang sama sekali lain.

Baca fail yang diselesaikan oleh nama perkhidmatan, termasuk apa-apa yang disertakannya:

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

Jika tindanan mewakilkan kepada direktori, menambah akaun setempat tidak mengubah apa-apa. Jika ia membaca akaun setempat, mencipta pengguna dalam direktori juga tidak mengubah apa-apa. Akaun mesti wujud di tempat tindanan melihat, dan itulah keseluruhan diagnosis dalam kebanyakan laporan ini.

Satu percubaan, dua log

Kaitkan satu sambungan gagal di kedua-dua belah pihak. Log OpenVPN menunjukkan hasil pemalam dan penolakan klien; log pengesahan sistem menunjukkan modul mana yang berjalan dan apa yang diputuskannya. Membaca kedua-duanya dalam tetingkap masa yang sama itulah yang memisahkan fail perkhidmatan yang hilang daripada tamat masa backend. Jurang dalam log pengesahan bermakna tindanan itu tidak pernah dicapai langsung.

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

Uji perkhidmatan itu secara langsung dengan utiliti yang bertutur PAM, supaya anda tidak menyahpepijat VPN dan tindanan pada masa yang sama. Ujian langsung yang berjaya dengan nama perkhidmatan dan akaun yang sama menyempitkan masalah kepada cara daemon menghantar kelayakan, bukan kepada akaun itu sendiri.

pamtester openvpn alice authenticate

Jika ujian langsung gagal dengan kelayakan yang sama yang berfungsi di konsol, tindanan itu tidak membaca sumber akaun yang anda anggap. Jika ia berjaya, lihat perbualan yang dijalankan oleh pemalam dan apa yang sebenarnya dihantar oleh klien. Jalankannya sekali juga dengan kata laluan yang sengaja salah, supaya anda melihat perbezaan antara penolakan dan ralat modul. Kedua-dua hasil itu kelihatan sama dalam log VPN dan sama sekali berbeza di sini.

Perkhidmatan khusus lebih baik daripada menyunting log masuk

Berikan VPN fail perkhidmatannya sendiri apabila keperluannya berbeza daripada log masuk interaktif, yang biasanya memang begitu. Menyunting login atau common-auth mengubah dasar bagi setiap program yang menyertakannya, dan orang seterusnya yang menyahpepijat masalah log masuk tidak berkaitan akan mewarisi perubahan anda.

Salin modul yang anda perlukan ke dalam fail perkhidmatan kecil, kekalkan urutannya secara eksplisit, dan catat siapa pemiliknya. Fail itulah yang perlu diperiksa apabila set semula kata laluan kelihatan tidak berkesan.

Apa yang dihantar oleh klien, dan apa yang tidak

Klien membekalkan nama pengguna dan kata laluan melalui gesaan atau fail yang disokongnya. Pemalam pelayan menyalurkan nilai-nilai itu ke dalam perbualan PAM; ia tidak membacanya daripada konfigurasi pelayan. Baris di sebelah pelayan yang kelihatan menakrifkan kata laluan tidak berbuat demikian, dan tiada penyuntingan profil akan mencipta akaun.

Nama pengguna dan kata laluan boleh wujud bersama sijil klien, dan mendayakan PAM bukanlah sebab untuk berhenti mengesahkan sijil. Kekalkan lapisan yang dimaksudkan oleh penggunaan itu dan betulkan hanya sumber akaun.

Penerimaan adalah dua hala: akaun yang dimaksudkan berjaya, dan akaun yang sepatutnya ditolak masih gagal. Fail README pemalam auth-pam mendokumenkan argumen perkhidmatan dan backend yang boleh dilayaninya, dan di situlah tempat untuk mengesahkan susunan yang cuba anda bina.