OpenVPN PAM: argument logowania to nazwa usługi, nie użytkownik

Na serwerze dodano użytkownika, hasło wpisano poprawnie, a połączenie nadal kończy się komunikatem AUTH_FAILED. Wiersz wtyczki zwykle wyjaśnia dlaczego: słowo po ścieżce wtyczki to nazwa usługi PAM i to ona decyduje, który stos modułów odpowiada na pytanie. To nie jest nazwa użytkownika ani wskaźnik do pliku haseł, który OpenVPN czyta sam.

Co wybiera drugie słowo

Wiersz konfiguracji przyjmuje ścieżkę wtyczki i jeden argument:

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

Ten argument jest przekazywany bibliotece PAM jako nazwa usługi, dzięki czemu uruchamiany jest stos w /etc/pam.d/openvpn. Jeśli wpiszesz tam login, zamiast tego otrzymasz interaktywną politykę logowania, z modułami, które ta polityka akurat zawiera w Twojej dystrybucji.

Użyj ścieżki wtyczki dostarczanej przez zainstalowany pakiet, a nie ścieżki skopiowanej z innego hosta. Nazwa pliku i katalog różnią się między dystrybucjami, a błędna ścieżka zawodzi przy starcie błędem wczytywania wtyczki, nie podczas uwierzytelniania.

Skąd stos naprawdę czyta konta

PAM to dyspozytor. Plik usługi wymienia moduły w kolejności, a pierwszy, który może odpowiedzieć, decyduje o wyniku. Stos wywołujący pam_unix czyta konta lokalne; stos wywołujący moduł LDAP lub RADIUS wysyła poświadczenia zupełnie gdzie indziej.

Przeczytaj plik, na który rozwiązuje się nazwa usługi, łącznie ze wszystkim, co zawiera:

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

Jeśli stos deleguje do katalogu, dodanie lokalnego konta niczego nie zmienia. Jeśli czyta konta lokalne, utworzenie użytkownika w katalogu też niczego nie zmienia. Konto musi istnieć tam, gdzie zagląda stos, i na tym polega cała diagnoza w większości tych zgłoszeń.

Jedna próba, dwa dzienniki

Skoreluj jedno nieudane połączenie po obu stronach. Dziennik OpenVPN pokazuje wynik wtyczki i odrzucenie klienta; dziennik uwierzytelniania systemu pokazuje, który moduł zadziałał i co postanowił. Czytanie ich w tym samym oknie czasowym jest tym, co oddziela brakujący plik usługi od przekroczenia limitu czasu backendu. Luka w dzienniku uwierzytelniania oznacza, że stos nigdy nie został osiągnięty.

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

Przetestuj usługę bezpośrednio narzędziem mówiącym po PAM, żebyś nie debugował jednocześnie VPN i stosu. Udany test bezpośredni z tą samą nazwą usługi i kontem zawęża problem do sposobu przekazywania poświadczeń przez demona, a nie do samego konta.

pamtester openvpn alice authenticate

Jeśli test bezpośredni zawodzi z tymi samymi poświadczeniami, które działają w konsoli, stos nie czyta założonego przez Ciebie źródła kont. Jeśli się udaje, przyjrzyj się rozmowie prowadzonej przez wtyczkę i temu, co klient naprawdę wysłał. Uruchom go też raz z celowo błędnym hasłem, żeby zobaczyć różnicę między odmową a błędem modułu. Te dwa wyniki wyglądają identycznie w dzienniku VPN, a tutaj zupełnie inaczej.

Dedykowana usługa bije edytowanie logowania

Daj VPN-owi własny plik usługi, gdy jego wymagania różnią się od logowania interaktywnego, co zwykle ma miejsce. Edycja login lub common-auth zmienia politykę dla każdego programu, który je zawiera, a następna osoba debugująca niepowiązany problem z logowaniem odziedziczy Twoją zmianę.

Skopiuj potrzebne moduły do małego pliku usługi, zachowaj jawną kolejność i zanotuj, kto jest jego właścicielem. To jest plik, który trzeba sprawdzić, gdy reset hasła wydaje się nie mieć żadnego efektu.

Co klient wysyła, a czego nie

Klient dostarcza nazwę użytkownika i hasło przez obsługiwane pytanie lub plik. Wtyczka serwera przekazuje te wartości do rozmowy PAM; nie czyta ich z konfiguracji serwera. Wiersz po stronie serwera, który wygląda, jakby definiował hasło, nie robi tego, i żadna edycja profilu nie utworzy konta.

Nazwa użytkownika i hasło mogą współistnieć z certyfikatami klienta, a włączenie PAM nie jest powodem, by przestać weryfikować certyfikaty. Zachowaj warstwy, które zakładało wdrożenie, i napraw tylko źródło kont.

Akceptacja jest dwustronna: zamierzone konto odnosi sukces, a konto, które powinno zostać odrzucone, nadal zawodzi. Plik README wtyczki auth-pam dokumentuje argument usługi i backendy, którym może służyć, i tam warto potwierdzić układ, który próbujesz zbudować.