A szerveren létrehoztak egy felhasználót, a jelszót helyesen írták be, és a kapcsolat mégis AUTH_FAILED hibával ér véget. A bővítmény sora általában megmagyarázza, miért: a bővítmény útvonala utáni szó egy PAM szolgáltatásnév, és ez dönti el, melyik modulverem válaszol a kérdésre. Ez nem felhasználónév, és nem is mutató egy jelszófájlra, amelyet OpenVPN maga olvasna.

Mit választ a második szó

A konfigurációs sor egy bővítményútvonalat és egy argumentumot vesz át:

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

Ezt az argumentumot a PAM könyvtár szolgáltatásnévként kapja meg, amitől a /etc/pam.d/openvpn alatti verem fut le. Ha oda login van írva, helyette az interaktív bejelentkezési házirendet kapja, azokkal a modulokkal, amelyeket ez a házirend a disztribúcióján éppen tartalmaz.

A telepített csomag által biztosított bővítményútvonalat használja, ne egy másik gazdagépről másolt útvonalat. A fájlnév és a könyvtár disztribúciónként eltér, és a hibás útvonal már indításkor bővítménybetöltési hibával bukik el, nem az azonosításnál.

Honnan olvassa a verem valójában a fiókokat

A PAM egy felosztó. A szolgáltatásfájl sorrendben listázza a modulokat, és az első, amelyik válaszolni tud, dönt az eredményről. A pam_unix modult hívó verem helyi fiókokat olvas; az LDAP vagy RADIUS modult hívó verem a hitelesítő adatokat egészen máshová küldi.

Olvassa el azt a fájlt, amelyre a szolgáltatásnév feloldódik, beleértve mindent, amit tartalmaz:

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

Ha a verem egy könyvtárnak delegál, a helyi fiók hozzáadása semmit nem változtat. Ha helyi fiókokat olvas, a felhasználó létrehozása a könyvtárban szintén semmit nem változtat. A fióknak ott kell léteznie, ahová a verem néz, és a legtöbb ilyen jelentésben ez a teljes diagnózis.

Egy kísérlet, két napló

Korreláljon egyetlen sikertelen kapcsolatot mindkét oldalon. Az OpenVPN naplója mutatja a bővítmény eredményét és a kliens elutasítását; a rendszer hitelesítési naplója mutatja, melyik modul futott és mit döntött. Az, hogy ugyanabban az időablakban olvassa őket, az különbözteti meg a hiányzó szolgáltatásfájlt a háttérrendszer időtúllépésétől. A hitelesítési naplóban lévő rés azt jelenti, hogy a vermet egyáltalán nem érték el.

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

Tesztelje a szolgáltatást közvetlenül egy PAM-ot beszélő segédprogrammal, hogy ne a VPN-t és a vermet hibakeresse egyszerre. Egy sikeres közvetlen teszt ugyanazzal a szolgáltatásnévvel és fiókkal arra szűkíti a problémát, hogyan adja át a démon a hitelesítő adatokat, nem magára a fiókra.

pamtester openvpn alice authenticate

Ha a közvetlen teszt ugyanazokkal a hitelesítő adatokkal bukik el, amelyek a konzolon működnek, a verem nem a feltételezett fiókforrást olvassa. Ha sikerül, nézze meg a bővítmény által folytatott beszélgetést és azt, amit a kliens ténylegesen küldött. Futtassa le egyszer szándékosan rossz jelszóval is, hogy lássa a különbséget az elutasítás és egy modulhiba között. Ez a két kimenet azonosnak látszik a VPN naplójában, és itt teljesen különbözik.

A külön szolgáltatás jobb, mint a bejelentkezés szerkesztése

Adjon a VPN-nek saját szolgáltatásfájlt, amikor a követelményei eltérnek az interaktív bejelentkezéstől, ami általában így van. A login vagy a common-auth szerkesztése minden olyan program házirendjét megváltoztatja, amely tartalmazza őket, és a következő ember, aki egy független bejelentkezési problémát hibakeres, megörökli a változtatását.

Másolja a szükséges modulokat egy kis szolgáltatásfájlba, tartsa egyértelműen a sorrendet, és jegyezze fel, kié. Ez az a fájl, amit ellenőrizni kell, amikor egy jelszó-visszaállítás hatástalannak tűnik.

Mit küld a kliens, és mit nem

A kliens felhasználónevet és jelszót a támogatott kérésén vagy fájlján keresztül ad meg. A szerverbővítmény ezeket az értékeket átadja a PAM-beszélgetésnek; nem a szerver konfigurációjából olvassa ki őket. Egy kiszolgálóoldali sor, amely úgy tűnik, mintha jelszót határozna meg, nem teszi ezt, és semmilyen profilszerkesztés nem hoz létre fiókot.

A felhasználónév és a jelszó együtt létezhet az ügyféltanúsítványokkal, és a PAM engedélyezése nem ok arra, hogy abbahagyja a tanúsítványok ellenőrzését. Tartsa meg a telepítés által szánt rétegeket, és csak a fiókforrást javítsa.

Az elfogadás kétirányú: a szánt fiók sikerül, és a visszautasítandó fiók továbbra is elbukik. A auth-pam bővítmény README-je dokumentálja a szolgáltatásargumentumot és a backendszolgáltatásokat, amelyeket kezelhet, és ott érdemes megerősíteni a felállást, amelyet építeni próbál.

Kapcsolódó cikkek