OpenVPN PAM: inloggningsargumentet är en tjänst, inte en användare

En användare lades till på servern, lösenordet skrevs rätt, och anslutningen slutar ändå med AUTH_FAILED. Pluginraden brukar förklara varför: ordet efter plugin-sökvägen är ett PAM-tjänstenamn, och det avgör vilken stack av moduler som svarar på frågan. Det är inte ett användarnamn, och det är inte en pekare till en lösenordsfil som OpenVPN läser själv.

Vad det andra ordet väljer

Konfigurationsraden tar en plugin-sökväg och ett argument:

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

Argumentet skickas till PAM-biblioteket som tjänstenamn, vilket gör att stacken i /etc/pam.d/openvpn är den som körs. Skriv login där och du får i stället den interaktiva inloggningspolicyn, med de moduler som den policyn råkar innehålla på din distribution.

Använd plugin-sökvägen som det installerade paketet tillhandahåller, inte en sökväg kopierad från en annan värd. Filnamnet och katalogen skiljer sig mellan distributioner, och en felaktig sökväg misslyckas vid start med ett plugin-inläsningsfel, inte vid autentiseringen.

Var stacken faktiskt läser konton

PAM är en distributör. Tjänstefilen listar moduler i ordning, och den första som kan svara avgör resultatet. En stack som anropar pam_unix läser lokala konton; en stack som anropar en LDAP- eller RADIUS-modul skickar autentiseringsuppgifterna någon helt annanstans.

Läs filen som tjänstenamnet löser upp till, inklusive allt den inkluderar:

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

Om stacken delegerar till en katalog ändrar det ingenting att lägga till ett lokalt konto. Om den läser lokala konton ändrar det heller ingenting att skapa användaren i katalogen. Kontot måste finnas där stacken tittar, och det är hela diagnosen i de flesta av de här rapporterna.

Ett försök, två loggar

Korrelera en enda misslyckad anslutning på båda sidor. OpenVPN-loggen visar pluginresultatet och klientens avvisning; systemets autentiseringslogg visar vilken modul som kördes och vad den beslutade. Att läsa dem i samma tidsfönster är det som skiljer en saknad tjänstefil från en backend-timeout. En lucka i autentiseringsloggen betyder att stacken aldrig nåddes.

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

Testa tjänsten direkt med ett verktyg som talar PAM, så att du inte felsöker VPN:et och stacken samtidigt. Ett lyckat direkt test med samma tjänstenamn och konto begränsar problemet till hur daemonen skickar autentiseringsuppgifter, inte till kontot självt.

pamtester openvpn alice authenticate

Om det direkta testet misslyckas med samma uppgifter som fungerar i en konsol läser stacken inte den kontokälla du antog. Om det lyckas, titta på samtalet som pluginmodulen kör och på vad klienten faktiskt skickade. Kör det också en gång med ett avsiktligt fel lösenord, så att du ser skillnaden mellan en avvisning och ett modulfel. De två utfallen ser identiska ut i VPN-loggen och helt olika här.

En egen tjänst slår att redigera inloggningen

Ge VPN:et en egen tjänstefil när dess krav skiljer sig från interaktiv inloggning, vilket de oftast gör. Att redigera login eller common-auth ändrar policyn för varje program som inkluderar dem, och nästa person som felsöker ett orelaterat inloggningsproblem ärver din ändring.

Kopiera modulerna du behöver till en liten tjänstefil, håll ordningen explicit och notera vem som äger den. Den filen är det man kontrollerar när en lösenordsåterställning verkar sakna effekt.

Vad klienten skickar, och vad den inte skickar

Klienten tillhandahåller ett användarnamn och ett lösenord via sin stödda fråga eller fil. Serverpluginmodulen skickar dessa värden in i PAM-samtalet; den läser dem inte från serverns konfiguration. En rad på serversidan som ser ut att definiera ett lösenord gör inte det, och ingen profilredigering skapar ett konto.

Användarnamn och lösenord kan samexistera med klientcertifikat, och att aktivera PAM är inte ett skäl att sluta verifiera certifikat. Behåll lagren som distributionen avsåg och reparera bara kontokällan.

Acceptans är tvåsidig: det avsedda kontot lyckas, och ett konto som borde avvisas misslyckas fortfarande. Filen README för auth-pam-pluginmodulen dokumenterar tjänsteargumentet och de backends som den kan stå framför, och det är stället att bekräfta den ordning du försöker bygga.