OpenVPN auth-user-pass: súbor, stdin alebo výzva? Ako vybrať

Ktorý zdroj prihlasovacích údajov použiť, rozhodujú tri veci: či pri konzole sedí človek, či tajomstvo môže žiť na disku a či na výzvu musí odpovedať iný proces. Ak vyberiete zle, klient nahlási problém so stdin, aj keď je heslo úplne platné, a to väčšinu ľudí bez dôvodu pošle na server. Najprv vyberte cestu; chybové hlásenia majú zmysel len vtedy, keď viete, ktorá cesta ich vyvolala.

Tri podmienky, ktoré to rozhodujú

Výzva v konzole je jediná cesta, ktorá potrebuje človeka, preto je jediná, ktorá v systemd unite alebo kontajneri ticho zlyhá. Ak človek spustí klienta a napíše heslo, nie je zapojený žiadny súbor a nič citlivé sa nedostane na disk. Ak sa klient spustí pri bootovaní, tá istá výzva sa zmení na zaseknutie a časový limit sa zvyčajne prejaví ako všeobecné zlyhanie pripojenia, nie ako chyba prihlasovacích údajov.

Súbor prihlasovacích údajov je správna odpoveď, keď proces štartuje bez dozoru a tajomstvo môže prežiť na disku pod kontrolovanou sadou oprávnení. Keď sa tajomstvo nesmie vôbec zapísať - zásada iba trezoru, krátkodobý token - potrebujete stream, ktorý klient dokáže otvoriť, čo v praxi znamená substitúciu procesu alebo pomocníka zapisujúceho do deskriptora súboru. Rozhranie na správu pokrýva štvrtý prípad: kontrolér, ktorý už spravuje životný cyklus tunela a dokáže odpovedať na otázky cez socket.

• Človek pri konzole, žiadna automatizácia: interaktívna výzva.
• Štart bez dozoru, tajomstvo sa smie uložiť: súbor prihlasovacích údajov s režimom 0600.
• Štart bez dozoru, tajomstvo sa nesmie uložiť: substitúcia procesu alebo fd, do ktorého zapisuje agent tajomstiev.
• Klienta vlastní iný proces: rozhranie na správu.

Keď sedia dve odpovede, vyberte tú, ktorá drží tajomstvo mimo argv a mimo histórie shellu. Heslo odovzdané ako argument programu môže čítať každý lokálny používateľ cez zoznam procesov, a toto odhalenie sa ťažko odvoláva.

Čo každá vstupná cesta skutočne robí

--auth-user-pass samo o sebe pýta v konzole používateľské meno a heslo. Keď dostane názov súboru, klient vezme prvý riadok ako používateľské meno a druhý ako heslo; nič nepodporuje úvodzovky, komentáre ani syntax kľúč-hodnota. To je celý formát, takže kto ho upravuje s očakávaním súboru INI, pokazí ho. Vložený blok <auth-user-pass> obsahuje tie isté dva riadky v profile, čo robí samotný profil tajomstvom a zaraďuje ho do rovnakej triedy zaobchádzania ako súkromný kľúč.

Ostatné dve cesty sú stream a socket. OpenVPN potrebuje len čitateľný deskriptor súboru, takže prijme substitúciu procesu, položku /dev/fd podporovanú rúrou alebo názov súboru, ktorý je v skutočnosti FIFO. Rozhranie na správu je iné povahy: klient sa pýta dohliadajúceho procesu na hodnoty namiesto toho, aby ich čítal sám. Ten rozdiel je dôležitý pri opätovnom pripojení: súbor prihlasovacích údajov, FIFO, do ktorého pomocník tajomstiev dokáže znova zapísať, aj rozhranie na správu dokážu dodať znova bez človeka; substitúcia procesu nie, pretože deskriptor sa pri prvom čítaní spotrebuje.

Súbor musí mať presne dva riadky

Väčšinu poškodených súborov prihlasovacích údajov pokrývajú dva režimy zlyhania. Editor vo Windows necháva konce CRLF, návrat vozíka sa stane súčasťou hesla a server odmietne hodnotu, ktorá na obrazovke vyzerá správne. Prázdny druhý riadok - prázdny riadok tam, kde má byť heslo - nechá klienta s prázdnym heslom, ktoré server odmietne, aj keď hodnota na obrazovke vyzerá správne. Nadbytočný nový riadok za heslom je neškodný. Píšte súbor zo shellu, nie z editora, a skontrolujte bajty:

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

Cesta je rovnako dôležitá ako obsah. Relatívna cesta sa vyhodnocuje voči pracovnému adresáru procesu, ktorý pri službe málokedy býva adresárom, kde ste testovali. Použite absolútnu cestu, nastavte súbor ako vlastníctvo účtu, ktorý klienta spúšťa, a udržujte režim 0600, aby ho skupina a ostatní nemohli čítať. Príručka OpenVPN 2.6 uvádza akceptované formy direktívy; pozrite si ju, kým vymyslíte tretiu.

Otestujte súbor, kým obviníte server. Spustenie openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 vypíše, či sa súbor otvoril a neskôr, či boli prihlasovacie údaje prijaté, čo vám povie, ktorú vrstvu zmeniť nabudúce.

Streamy, stdin a chyby, ktoré produkujú

Poslať heslo rúrou skúša väčšina ako prvé a je to cesta s najviac prekvapeniami. Substitúcia procesu funguje, pretože klient potrebuje len čitateľný deskriptor: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Odovzdanie /dev/stdin funguje len vtedy, keď je stdin v okamihu otázky klienta ešte otvorený a čitateľný, čo v potrubí, ktoré ho už spotrebovalo, neplatí.

ERROR: could not read Auth username from stdin má dve rôzne príčiny. Pri niektorých klientoch 2.3.x správa pochádzala z defektu spracovania stdin, ktorý neskoršie vydania 2.3 opravili, takže taký starý klient sa zlepší len aktualizáciou. Pri súčasnom klientovi to isté znenie znamená, že klient požiadal o vstup z konzoly a stdin nebol terminál - presne situácia v systemd unite, úlohe cron alebo kontajneri spustenom bez -t.

auth-nocache pridáva tretiu slučku, ktorá vyzerá ako pokazené heslo. Zahadzuje prihlasovacie údaje z pamäte po použití, takže opätovné pripojenie vyvolané zmenou siete nemá čo prehrať a výzva sa vráti. To je direktíva fungujúca tak, ako bola navrhnutá. auth-nocache mení to, čo klient drží v pamäti, nie to, čo si server alebo poskytovateľ identity myslí o účte, takže celá oprava je znova dodať ten istý súbor, znovu načítaný pri reštarte - a pri spravovanom pripojení má toto dodanie prísť zo schváleného úložiska tajomstiev, nie z hesla v skripte.

Rozhranie na správu, keď výzvu vlastní iný proces

Kontrolér, ktorý už dohliada na tunel, dokáže odpovedať aj na jeho otázky. Spustite klienta s --management 127.0.0.1 7505, čítajte stavové riadky a sledujte >PASSWORD:Need 'Auth' username/password. Kontrolér odpovedá username "Auth" alice, po ktorom nasleduje password "Auth" ... na samostatných príkazových riadkoch. Token 'Auth' opakuje identifikátor z požiadavky a musí sa zhodovať, inak sa odpoveď ignoruje a klient čaká.

Cena je stavový stroj, ktorý teraz vlastníte: poradie pripojení, reštarty klienta a lokálny socket, ku ktorému sa ostatní používatelia na hostiteľovi nesmú dostať. Kupujete prihlasovacie údaje dodané za behu, bez súboru na disku a bez výzvy, ktorá sa môže zaseknúť. Ak nič iné vo vašom stacku už nehovorí týmto protokolom, táto cesta pridáva komponent na údržbu.

Zlyhania, ktoré vyzerajú ako problémy s prihlasovacími údajmi

TLS podanie ruky, ktoré sa nikdy nedokončí, alebo VERIFY ERROR: depth=0, error=certificate signature failure, je problém dôvery a nastáva skôr, než sa prečíta akékoľvek používateľské meno. Klient proto tcp namierený na UDP poslucháč zlyhá na tom istom mieste: pakety sa nikdy nedostanú do fázy overenia, takže každé heslo vyzerá nesprávne asociáciou. Nechajte overovanie certifikátov zapnuté, kým sa prihlasovacie údaje odošlú; známa výzva nič nehovorí o tom, kto heslo dostane. Skontrolujte reťaz certifikátov, spoločný názov a transport, kým sa dotknete prihlasovacích údajov.

Chyby shellu v skripte, ktorý skladá profil, sú druhá falošná stopa. Chýbajúca medzera v [ ! -f "$file" ] vytvorí command not found, skript sa zastaví skoro, profil sa nikdy neprestavia a klient sa spustí s predchádzajúcim. Tá chyba patrí shellu, nie overovaniu, a žiadne prepisovanie hesla ju neodstráni.

Nie každá výzva v tomto toku je tento prihlasovací údaj. Prístupová fráza súkromného kľúča, prihlásenie cez HTTP proxy a heslo služby sú tri rôzne tajomstvá žiadané v rôznych fázach a prístupovú frázu kľúča zvyčajne spracúva klient alebo agent, nie auth-user-pass. Ak sa výzva objaví skôr, než je TLS relácia vytvorená, odpovedáte na nesprávnu otázku a žiadne resetovanie účtu nepomôže. Po vylúčení nesprávnej výzvy začínajú zostávajúce kontroly na najskoršej vrstve:

• Čítajte prvú chybu protokolu, nie posledný riadok prihlasovacích údajov: TLS, potom overenie, potom push.
• Potvrďte, že súbor má dva riadky, neobsahuje návraty vozíka a je uvedený absolútnou cestou.
• Potvrďte, že profil a príkazový riadok si o direktíve neodporujú.
• Oddeľte "prihlasovacie údaje prijaté" od "prevádzka tečie" - smerovanie a DNS sú neskoršia vrstva.

Keď klient dosiahne fázu push, prestaňte sa pozerať na prihlasovacie údaje a začnite čítať trasy a DNS servery, ktoré server poslal. To je ďalší problém a nemá nič spoločné s heslom, ktoré ste práve opravili.