Uživatel byl na serveru přidán, heslo bylo zadáno správně, a připojení přesto končí na AUTH_FAILED. Řádek modulu obvykle vysvětluje proč: slovo za cestou k modulu je název služby PAM a rozhoduje o tom, který zásobník modulů odpovídá na dotaz. Není to uživatelské jméno a není to ukazatel na soubor s hesly, který OpenVPN čte sám.

Co vybírá druhé slovo

Konfigurační řádek bere cestu k modulu a jeden argument:

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

Tento argument se knihovně PAM předá jako název služby, takže se spustí zásobník v /etc/pam.d/openvpn. Napíšete-li tam login, dostanete interaktivní zásady přihlášení, přesně s těmi moduly, které tyto zásady na vaší distribuci obsahují.

Použijte cestu k modulu, kterou poskytuje nainstalovaný balíček, ne cestu zkopírovanou z jiného hostitele. Název souboru i adresář se mezi distribucemi liší a špatná cesta selže už při startu chybou načtení modulu, ne při autentizaci.

Odkud zásobník účty skutečně čte

PAM je dispečer. Soubor služby vypisuje moduly v pořadí a první, který dokáže odpovědět, rozhoduje o výsledku. Zásobník volající pam_unix čte místní účty; zásobník volající modul LDAP nebo RADIUS posílá přihlašovací údaje úplně jinam.

Přečtěte si soubor, na který se název služby překládá, včetně všeho, co obsahuje:

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

Pokud zásobník deleguje na adresář, přidání místního účtu nic nezmění. Pokud čte místní účty, založení uživatele v adresáři také nic nezmění. Účet musí existovat tam, kam se zásobník dívá, a v tom spočívá celá diagnóza ve většině těchto hlášení.

Jeden pokus, dva záznamy

Spojte jedno neúspěšné připojení na obou stranách. Protokol OpenVPN ukazuje výsledek modulu a odmítnutí klienta; systémový protokol autentizace ukazuje, který modul běžel a co rozhodl. Čtení obou ve stejném časovém okně je to, co odděluje chybějící soubor služby od časového limitu backendu. Mezera v protokolu autentizace znamená, že zásobník nebyl vůbec zasažen.

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

Otestujte službu přímo nástrojem, který mluví s PAM, abyste neladili VPN a zásobník zároveň. Úspěšný přímý test se stejným názvem služby a účtem zúží problém na to, jak démon předává přihlašovací údaje, ne na účet samotný.

pamtester openvpn alice authenticate

Pokud přímý test selže se stejnými údaji, které fungují na konzoli, zásobník nečte vámi předpokládaný zdroj účtů. Pokud uspěje, podívejte se na konverzaci, kterou modul vede, a na to, co klient skutečně poslal. Spusťte jej také jednou se záměrně špatným heslem, abyste viděli rozdíl mezi odmítnutím a chybou modulu. Tyto dva výsledky vypadají v protokolu VPN stejně a zde zcela odlišně.

Vyhrazená služba je lepší než úprava přihlášení

Dejte VPN vlastní soubor služby, když se její požadavky liší od interaktivního přihlášení, což obvykle dělají. Úprava login nebo common-auth mění zásady pro každý program, který je zahrnuje, a další člověk, který bude ladit nesouvisející problém s přihlášením, zdědí vaši změnu.

Zkopírujte potřebné moduly do malého souboru služby, udržujte pořadí explicitní a poznamenejte, kdo jej vlastní. Právě tento soubor je třeba zkontrolovat, když se zdá, že obnovení hesla nemá žádný účinek.

Co klient posílá a co ne

Klient dodává uživatelské jméno a heslo prostřednictvím podporované výzvy nebo souboru. Modul serveru předává tyto hodnoty do konverzace PAM; nečte je z konfigurace serveru. Řádek na straně serveru, který vypadá, že definuje heslo, to nedělá, a žádná úprava profilu účet nevytvoří.

Uživatelské jméno a heslo mohou existovat vedle klientských certifikátů, a zapnutí PAM není důvod přestat ověřovat certifikáty. Zachovejte vrstvy, které nasazení zamýšlelo, a opravte jen zdroj účtů.

Přijetí je oboustranné: zamýšlený účet uspěje a účet, který má být odmítnut, stále selhává. Soubor README modulu auth-pam dokumentuje argument služby a backendy, které může zastřešit, a právě tam si potvrdíte uspořádání, které se snažíte postavit.

Související články