Javítás: az OpenVPN nem tudta beolvasni az Auth felhasználónevet a szabványos bemenetről

could not read Auth username from stdin hitelesítési problémának látszik, és nem az. Az OpenVPN megpróbálta bekérni a felhasználónevet a szabványos bemenetről, nem talált semmi olvashatót, és leállt, mielőtt valaha kapcsolatba lépett volna a kiszolgálóval. A fiók teljesen érvényes lehet; a folyamatnak egyszerűen nincs kitől kérdeznie.

Ezért az első hasznos lépés annak megerősítése, mit olvas a kliens, nem a kapcsolat újbóli megpróbálása vagy a kiszolgálóoldali beállítások módosítása. Menjen végig az alábbi ellenőrzéseken sorrendben, és álljon meg az elsőnél, amelyik sikertelen.

Olvassa a hibát helyi bemeneti hibaként

Amikor auth-user-pass fájlargumentum nélkül jelenik meg, a kliens kérdezni szeretne. Interaktív héjban ez a kérés működik, mert a folyamat rendelkezik terminállal. systemd, cron-feladat vagy konténer alatt a szabványos bemenet általában üres, és az olvasás azonnal visszatér azzal a hibával, amelyet lát.

Az üzenet megnevezi a sikertelen mezőt is, felhasználónevet vagy jelszót, ami megmutatja, meddig jutott az olvasás. A hiányzó felhasználónév azt jelenti, hogy a folyamat semmit sem tudott beolvasni. A sikeres felhasználónév utáni hiányzó jelszó azt jelenti, hogy a bemeneti adatfolyam a két olvasás között véget ért, ami a félig megírt fájlra vagy a lezárt csőre jellemző.

Erősítse meg a kliens saját nézetét, mielőtt bármi mást módosítana. Futtassa előtérben ugyanazzal a konfigurációval és ugyanazzal a felhasználóval, és figyelje, megjelenik-e a kérés. Ha a héjában megjelenik, de a szolgáltatáskezelő alatt nem, a különbség a bemeneti forrásban van, nem a hitelesítő adatokban. Az unit-fájl és a héj környezetének gyors összehasonlítása általában megmutatja, melyik biztosít terminált.

Adjon a szolgáltatásnak támogatott hitelesítőadat-forrást

A támogatott, felügyelet nélküli forrás egy hitelesítőadat-fájl, amelyet argumentumként adnak át a auth-user-pass számára. A fájlt egyszerű szövegként olvassa be: az első sor a felhasználónév, a második a jelszó. Abszolút útvonallal mutasson rá, például /etc/openvpn/client/creds , hogy a szolgáltatásfiók munkakönyvtára ne változtathassa meg az utasítás jelentését.

A jogosultságok legalább olyan fontosak, mint az útvonal. A fájlnak olvashatónak kell lennie a klienst futtató fiók számára, és nem mindenki másnak, valamint a szolgáltatásfiók vagy a root tulajdonában kell lennie egy olyan csoporttal, amely tartalmazza a szolgáltatást. Ellenőrizze az olvashatóságot e fiókként, anélkül hogy kiírná a tartalmat.

A relatív útvonal a csendes hibaüzemmód. A profil lehet az egyik könyvtárban, miközben a systemd máshol indítja a folyamatot, így a héjában feloldható fájl a szolgáltatás számára nem oldható fel. Helyezze át a hitelesítő adatokat egy rögzített helyre, és hivatkozzon rájuk abszolút módon. Ezután indítsa el egyszer a szolgáltatást, és erősítse meg, hogy ugyanazt az útvonalat használja, ahelyett hogy a profilszerkesztő nézetére bízná magát.

Ha az üzembe helyezés egyszeri kódot vagy más interaktív kihívást igényel, döntse el, hogy a kliens munkafolyamata valóban támogatja-e ezt felügyelet nélkül. A statikus jelszót tartalmazó fájl nem tud forgó kódra válaszolni, és a megválaszolhatatlan kérés ismétlése nem ad információt.

Miért nem segít a script-security

script-security szabályozza, hogy a kliens futtathat-e szkripteket, és mennyit adhat át nekik, beleértve azt is, hogy átadható-e jelszó egy szkriptnek környezeti változón keresztül. Arról nem mond semmit, honnan származik a felhasználónév és a jelszó.

Magasabb szintre emelése gyakori reflex, mert az üzenet említi az Auth szót, de ez a szkriptjogosultságokat változtatja meg, nem a bemeneti forrást, és kiszélesíti, mit futtathat a kliens. Ha egy segédszkript a tervezés része, először a bemeneti forrást javítsa, és tartsa a biztonsági szintet a legalacsonyabb értéken, amelyre az üzembe helyezésnek szüksége van.

A kezelőfelület jogszerű alternatíva. Egy frontend csatlakozhat hozzá, fogadhatja a hitelesítőadat-kérést, és felhasználónévvel és jelszóval válaszolhat, így működnek egyes GUI-k. Ha használja, kösse helyi címhez, védje kezelői jelszófájllal, és korlátozza, ki csatlakozhat, mert ez a kliens vezérlőcsatornája.

Ellenőrizze a következő szakaszt, miután a kliens beolvasta a fájlt

Amint a kliens be tudja olvasni a hitelesítő adatokat, a következő hiba már valódi csere a kiszolgálóval, és üzenetének más a jelentése. Az ezen a szakaszon bekövetkező hitelesítési hiba azt jelenti, hogy a kiszolgáló elutasította a fiókot; a kihívásválasz azt jelenti, hogy a kiszolgáló másik tényezőt kér. Ezeket új problémaként kezelje, ne ugyanaz ismétléseként.

Tesztelje a teljes útvonalat úgy, ahogy a szolgáltatás futtatni fogja: ugyanaz a fiók, ugyanaz a munkakönyvtár, ugyanaz az unit-környezet. Az a kapcsolat, amely csak a héjából indítva működik, annak a jele, hogy egy környezeti változó vagy egy terminál még mindig a folyamat része.

Ezután tartsa a titkokat ott, ahová tartoznak. A parancssori argumentumokban lévő jelszavak megjelennek a folyamattáblában, a hibakeresési kimenetben lévők pedig jegyekbe kerülnek. Használjon védett fájlt vagy a kezelőfelületet, tartsa a naplókat olyan szinten, amely nem ismétli meg a hitelesítő adatokat, és cserélje a fájlt, amikor bárki hozzáféréssel távozik.

Ellenőrzőlista: abszolút hitelesítőadat-útvonal, szolgáltatásfiókként olvasható, nincs szükség terminálra, a script-security a minimumán, kezelőfelület csak akkor, ha kötött és hitelesített, és az abból származó kiszolgálóválasz külön eseményként kezelve.