OpenVPN auth-user-pass: fájl, stdin vagy kérés? Így válasszon

Három dolog dönti el, melyik hitelesítőadat-forrást használja: ül-e valaki a konzolnál, maradhat-e a titok a lemezen, és egy másik folyamatnak kell-e válaszolnia a kérésre. Rossz választás esetén a kliens stdin-problémát jelent, miközben a jelszó teljesen érvényes, és ez ok nélkül a szerverhez küldi a legtöbb embert. Először az utat válassza ki; a hibaüzenetek csak akkor van értelme, ha tudja, melyik út hozta létre őket.

A három feltétel, amely ezt eldönti

A konzolkérés az egyetlen út, amelyhez ember kell, ezért ez az egyetlen, amely csendben elbukik egy systemd unitban vagy konténerben. Ha egy ember indítja a klienst és beírja a jelszót, nem vesz részt fájl, és semmi érzékeny nem kerül a lemezre. Ha a kliens induláskor indul, ugyanaz a kérés megakadássá válik, és az időtúllépés általában általános kapcsolódási hibaként jelenik meg, nem hitelesítőadat-hibaként.

A hitelesítőadat-fájl a helyes válasz, amikor a folyamat felügyelet nélkül indul, és a titok túlélhet a lemezen egy ellenőrzött jogosultságkészlet alatt. Amikor a titkot egyáltalán nem szabad kiírni - csak széf politika, rövid életű token - olyan streamre van szükség, amelyet a kliens meg tud nyitni, ami a gyakorlatban folyamathelyettesítést vagy fájlleíróba író segédeszközt jelent. A felügyeleti felület a negyedik esetet fedi le: egy vezérlő, amely már kezeli az alagút életciklusát, és socketen keresztül tud válaszolni a kérdésekre.

• Ember a konzolnál, automatizálás nélkül: interaktív kérés.
• Felügyelet nélküli indítás, a titok tárolható: hitelesítőadat-fájl 0600 módban.
• Felügyelet nélküli indítás, a titok nem tárolható: folyamathelyettesítés vagy egy fd, amelybe titokügynök ír.
• Egy másik folyamat birtokolja a klienst: felügyeleti felület.

Ha két válasz is illik, azt válassza, amely a titkot az argv-n és a shell előzményein kívül tartja. A programargumentumként átadott jelszót minden helyi felhasználó olvashatja a folyamatlistán keresztül, és ezt a kitettséget nehéz visszavonni.

Mit tesz valójában az egyes bemeneti utak

--auth-user-pass önmagában felhasználónevet és jelszót kér a konzolon. Ha fájlnevet kap, a kliens az első sort veszi felhasználónévként és a másodikat jelszóként; semmi nem támogatja az idézőjeleket, megjegyzéseket vagy a kulcs-érték szintaxist. Ez a teljes formátum, ezért aki INI-fájlt várva szerkeszti, elrontja. A beágyazott <auth-user-pass> blokk ugyanazt a két sort tartalmazza a profilon belül, ami magát a profilt titokká teszi, és ugyanabba a kezelési osztályba sorolja, mint egy privát kulcsot.

A másik két út egy stream és egy socket. A OpenVPN csak egy olvasható fájlleírót igényel, ezért elfogad folyamathelyettesítést, csővel támogatott /dev/fd bejegyzést vagy olyan fájlnevet, amely valójában FIFO. A felügyeleti felület más természetű: a kliens egy felügyelő folyamattól kéri az értékeket, ahelyett hogy maga olvasná őket. Ez a különbség újracsatlakozáskor számít: a hitelesítőadat-fájl, az a FIFO, amelybe egy titoksegéd újra írhat, és a felügyeleti felület ember nélkül is újra tudja szolgáltatni; a folyamathelyettesítés nem, mert a leíró az első olvasáskor elfogy.

A fájlnak pontosan két sornak kell lennie

Két hibatípus fedi a legtöbb törött hitelesítőadat-fájlt. A Windows szerkesztője CRLF végződéseket hagy, a kocsi vissza a jelszó részévé válik, és a szerver elutasít egy értéket, amely a képernyőn helyesnek látszik. Az üres második sor - üres sor ott, ahol a jelszónak lennie kellene - üres jelszóval hagyja a klienst, amelyet a szerver elutasít, pedig az érték a képernyőn helyesnek látszik. A jelszó utáni extra sortörés ártalmatlan. A fájlt shellből írja, ne szerkesztőből, és ellenőrizze a bájtokat:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Az út ugyanolyan fontos, mint a tartalom. A relatív út a folyamat munkakönyvtárához képest oldódik fel, amely szolgáltatás esetén ritkán az a könyvtár, ahol tesztelt. Használjon abszolút utat, tegye a fájlt a klienst futtató fiók tulajdonává, és tartsa meg a 0600 módot, hogy a csoport és mások ne olvashassák. Az OpenVPN 2.6 kézikönyve felsorolja az utasítás elfogadott formáit; nézze meg, mielőtt harmadikat talál ki.

Tesztelje a fájlt, mielőtt a szervert hibáztatja. A openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 futtatása kiírja, hogy megnyílt-e a fájl, és később, hogy elfogadták-e a hitelesítő adatokat, ami megmondja, melyik réteget kell következőként módosítani.

Streamek, stdin és az általuk termelt hibák

A jelszó csőbe tétele az első, amit a legtöbben kipróbálnak, és a legtöbb meglepetést hozó út. A folyamathelyettesítés azért működik, mert a kliensnek csak egy olvasható leíró kell: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). A /dev/stdin átadása csak akkor működik, ha a stdin még nyitott és olvasható abban a pillanatban, amikor a kliens kérdez, ami egy már elfogyasztott csővezetékben nem igaz.

ERROR: could not read Auth username from stdin két különböző okkal rendelkezik. Egyes 2.3.x klienseken az üzenet egy stdin-kezelési hibából származott, amelyet későbbi 2.3 kiadások javítottak, így egy ilyen régi kliens csak frissítéssel javul. Egy mai kliensen ugyanez a szöveg azt jelenti, hogy a kliens konzolbevitelt kért, és a stdin nem terminál volt - pontosan az a helyzet egy systemd unitban, egy cron-feladatban vagy egy -t nélkül indított konténerben.

auth-nocache hozzáad egy harmadik hurkot, amely törött jelszónak látszik. Használat után kidobja a hitelesítő adatokat a memóriából, így a hálózatváltozás által kiváltott újracsatlakozásnak nincs mit újrajátszania, és a kérés visszatér. Ez az utasítás úgy működik, ahogy tervezték. A auth-nocache azt változtatja meg, amit a kliens a memóriában tart, nem azt, amit a szerver vagy az identitásszolgáltató a fiókról gondol, ezért a teljes javítás ugyanannak a fájlnak az újraszolgáltatása, amely újraindításkor újra beolvasódik - és kezelt kapcsolat esetén ezt a szolgáltatást a jóváhagyott titoktárból kell venni, nem egy szkriptben lévő jelszóból.

A felügyeleti felület, amikor egy másik folyamat birtokolja a kérést

Az a vezérlő, amely már felügyeli az alagutat, a kérdésekre is válaszolhat. Indítsa a klienst --management 127.0.0.1 7505 értékkel, olvassa az állapotsorokat, és figyelje a >PASSWORD:Need 'Auth' username/password mintát. A vezérlő username "Auth" alice válasszal felel, amelyet külön parancssorokon password "Auth" ... követ. A 'Auth' token megismétli a kérés azonosítóját, és egyeznie kell, különben a választ figyelmen kívül hagyja, és a kliens vár.

Az ár egy állapotgép, amely most az Öné: kapcsolódási sorrend, kliensek újraindítása és egy helyi socket, amelyet a hoszt többi felhasználója nem érhet el. Amit kap, az futásidőben szolgáltatott hitelesítő adat, lemezen lévő fájl nélkül és megakadható kérés nélkül. Ha a verem más eleme még nem beszéli a protokollt, ez az út hozzáad egy karbantartandó komponenst.

Hitelesítőadat-problémának látszó hibák

Egy soha be nem fejeződő TLS kézfogás, vagy egy VERIFY ERROR: depth=0, error=certificate signature failure, bizalmi probléma, és még azelőtt történik, hogy bármely felhasználónevet beolvasnának. Egy UDP-figyelőre irányított proto tcp kliens ugyanott bukik el: a csomagok soha nem érik el a hitelesítési fázist, ezért minden jelszó hibásnak látszik az asszociáció miatt. Tartsa bekapcsolva a tanúsítvány-ellenőrzést, mielőtt a hitelesítő adat elküldésre kerül; egy ismerős kérés semmit nem mond arról, ki kapja a jelszót. Ellenőrizze a tanúsítványláncot, a köznapi nevet és az átvitelt, mielőtt hozzányúl a hitelesítő adathoz.

A profilt összeállító szkript shell-hibái a másik hamis nyom. Egy hiányzó szóköz a [ ! -f "$file" ] belsejében command not found eredményez, a szkript korán leáll, a profil soha nem épül újra, és a kliens az előzővel indul. Ez a hiba a shellhez tartozik, nem a hitelesítéshez, és a jelszó bármennyi újragépelése sem törli.

Nem minden kérés ebben a folyamatban ez a hitelesítő adat. A privát kulcs jelmondata, egy HTTP-proxy bejelentkezés és a szolgáltatás jelszava három különböző titok, amelyet különböző fázisokban kérnek, és a kulcs jelmondatát általában a kliens vagy egy ügynök kezeli, nem az auth-user-pass. Ha a kérés azelőtt jelenik meg, hogy a TLS-munkamenet felállna, rossz kérdésre válaszol, és semmilyen fiók-visszaállítás nem segít. Miután a rossz kérést kizárta, a fennmaradó ellenőrzések a legkorábbi rétegnél kezdődnek:

• Az első protokollhibát olvassa, ne az utolsó hitelesítőadat-sort: TLS, aztán hitelesítés, aztán push.
• Erősítse meg, hogy a fájl két soros, nincs benne kocsi vissza, és abszolút úttal hivatkoznak rá.
• Erősítse meg, hogy a profil és a parancssor nem mond ellent egymásnak az utasítással kapcsolatban.
• Válassza szét a "hitelesítő adatok elfogadva" és a "forgalom folyik" esetét - az útválasztás és a DNS későbbi réteg.

Amikor a kliens eléri a push fázist, hagyja abba a hitelesítő adatok nézését, és kezdje el olvasni a szerver által küldött útvonalakat és DNS-szervereket. Az a következő probléma, és semmi köze ahhoz a jelszóhoz, amelyet épp most javított.