OpenVPN auth-user-pass: lêer, stdin of opdrag? Hoe om te kies

Drie dinge bepaal watter geloofsbron jy moet gebruik: of ’n persoon by die konsole sit, of die geheim op skyf mag leef, en of ’n ander proses die opdrag moet beantwoord. Kry die keuse verkeerd en die kliënt rapporteer ’n stdin-probleem terwyl die wagwoord heeltemal geldig is, wat die meeste mense sonder rede na die bediener stuur. Kies eers die pad; die foutboodskappe maak net sin sodra jy weet watter pad hulle voortgebring het.

Die drie voorwaardes wat dit bepaal

Die konsole-opdrag is die enigste pad wat ’n mens nodig het, dus is dit die enigste een wat stilweg faal in ’n systemd-eenheid of ’n houer. As ’n persoon die kliënt begin en die wagwoord tik, is geen lêer betrokke nie en beland niks sensitiefs op die skyf nie. As die kliënt by selflaai begin, word dieselfde opdrag ’n hang, en die tydsverloop verskyn gewoonlik as ’n generiese verbindingsfout eerder as ’n geloofsfout.

’n Geloofsbrief-lêer is die regte antwoord wanneer die proses onbewaak begin en die geheim onder ’n beheerde toestemmingstel op die skyf mag oorleef. Wanneer die geheim glad nie geskryf mag word nie – ’n slegs-kluis-beleid, ’n kortstondige teken – het jy ’n stroom nodig wat die kliënt kan oopmaak, wat in die praktyk prosesvervanging of ’n helper beteken wat in ’n lêerbeskrywer skryf. Die bestuurskoppelvlak dek die vierde geval: ’n beheerder wat reeds die tonnel se lewensiklus bestuur en vrae oor ’n sok kan beantwoord.

• Mens by die konsole, geen outomatisering: interaktiewe opdrag.
• Onbewaakte begin, geheim mag gestoor word: geloofsbrief-lêer met modus 0600.
• Onbewaakte begin, geheim mag nie gestoor word nie: prosesvervanging of ’n fd wat deur ’n geheime-agent geskryf word.
• Nog ’n proses besit die kliënt: bestuurskoppelvlak.

Wanneer twee antwoorde pas, verkies die een wat die geheim uit argv en uit die shell-geskiedenis hou. ’n Wagwoord wat as programargument deurgegee word, is deur elke plaaslike gebruiker via die proseslys leesbaar, en daardie blootstelling is moeilik om ongedaan te maak.

Wat elke invoerpad werklik doen

--auth-user-pass op sy eie vra vir ’n gebruikersnaam en ’n wagwoord op die konsole. Met ’n lêernaam neem die kliënt reël een as die gebruikersnaam en reël twee as die wagwoord; niks ondersteun aanhaling, kommentaar of sleutel-waarde-sintaksis nie. Dit is die hele formaat, so enigiemand wat dit wysig in die verwagting van ’n INI-lêer, breek dit. ’n Inlyn <auth-user-pass>-blok hou dieselfde twee reëls binne die profiel, wat die profiel self ’n geheim maak en dit in dieselfde hanteringsklas as ’n private sleutel plaas.

Die ander twee paaie is ’n stroom en ’n sok. OpenVPN het net ’n leesbare lêerbeskrywer nodig, dus sal dit ’n prosesvervanging, ’n pyp-gedraagde /dev/fd-inskrywing of ’n lêernaam wat werklik ’n FIFO is, aanvaar. Die bestuurskoppelvlak verskil in wese: die kliënt vra ’n toesighoudende proses vir die waardes in plaas daarvan om dit self te lees. Daardie verskil maak saak by herverbinding: ’n geloofsbrief-lêer, ’n FIFO wat ’n geheime-helper weer kan skryf, en die bestuurskoppelvlak kan sonder ’n mens weer voorsien; prosesvervanging kan nie, want die beskrywer word by die eerste lees verteer.

Die lêer moet presies twee reëls wees

Twee foutmodusse dek die meeste gebreekte geloofsbrief-lêers. ’n Windows-redigeerder laat CRLF-eindes, die karretjie-terugkeer word deel van die wagwoord, en die bediener verwerp ’n waarde wat op die skerm korrek lyk. ’n Leë tweede reël – ’n leë lyn waar die wagwoord hoort – laat die kliënt met ’n leë wagwoord, wat die bediener verwerp selfs al lyk die waarde op die skerm reg. ’n Volgende nuwe reël ná die wagwoord is onskadelik. Skryf die lêer uit die shell, nie uit ’n redigeerder nie, en kontroleer die grepe:

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

Die pad maak net soveel saak as die inhoud. ’n Relatiewe pad word teen die proses se werkligging opgelos, wat vir ’n diens selde die gids is waar jy getoets het. Gebruik ’n absolute pad, maak die lêer die eiendom van die rekening wat die kliënt laat loop, en hou modus 0600 sodat groep en ander dit nie kan lees nie. Die OpenVPN 2.6-handleiding lys die aanvaarde vorms van die riglyn; kontroleer dit voordat jy ’n derde een uitdink.

Toets die lêer voordat jy die bediener blameer. Om openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 te laat loop, druk of die lêer oopgemaak is en, later, of die geloofsbriewe aanvaar is, wat jou vertel watter laag om volgende te verander.

Strome, stdin en die foute wat hulle oplewer

Om die wagwoord in te pyp is die eerste ding wat die meeste mense probeer en die pad met die meeste verrassings. Prosesvervanging werk omdat die kliënt net ’n leesbare beskrywer nodig het: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Om /dev/stdin deur te gee werk net wanneer stdin nog oop en leesbaar is op die oomblik dat die kliënt vra, wat nie waar is in ’n pyplyn wat dit al verteer het nie.

ERROR: could not read Auth username from stdin het twee verskillende oorsake. Op sommige 2.3.x-kliënte het die boodskap gekom van ’n stdin-hanteringsfout wat latere 2.3-vrystellings reggemaak het, so ’n kliënt so oud verbeter net deur op te gradeer. Op ’n huidige kliënt beteken dieselfde bewoording dat die kliënt vir konsole-invoer gevra het en stdin nie ’n terminaal was nie – presies die situasie in ’n systemd-eenheid, ’n cron-taak, of ’n houer wat sonder -t begin is.

auth-nocache voeg ’n derde lus by wat soos ’n gebreekte wagwoord lyk. Dit laat val die geloofsbriewe ná gebruik uit die geheue, so ’n herverbinding wat deur ’n netwerkverandering veroorsaak word, het niks om te herspeel nie en die opdrag keer terug. Dit is die riglyn wat werk soos ontwerp. auth-nocache verander wat die kliënt in die geheue hou, nie wat die bediener of die identiteitsverskaffer van die rekening dink nie, so die hele oplossing is om dieselfde lêer weer te voorsien, wat by herbegin weer gelees word – en vir ’n bestuurde verbinding moet daardie voorsiening uit die goedgekeurde geheimewinkel kom, nie ’n wagwoord in ’n script nie.

Die bestuurskoppelvlak wanneer ’n ander proses die opdrag besit

’n Beheerder wat reeds die tonnel toesig hou, kan ook sy vrae beantwoord. Begin die kliënt met --management 127.0.0.1 7505, lees die toestandlyne, en let op >PASSWORD:Need 'Auth' username/password. Die beheerder antwoord met username "Auth" alice gevolg deur password "Auth" ... op afsonderlike opdraglyne. Die 'Auth'-teken eggo die identifiseerder uit die versoek en moet ooreenstem, anders word die antwoord geïgnoreer en die kliënt wag.

Die koste is ’n toestandmasjien wat jy nou besit: verbindingsordenings, kliënt-herbeginsels, en ’n plaaslike sok wat ander gebruikers op die gasheer nie mag bereik nie. Wat jy koop, is ’n geloofsbrief wat by looptyd voorsien word, met geen lêer op skyf en geen opdrag wat kan hang nie. As niks anders in jou stapel reeds die protokol praat nie, voeg hierdie pad ’n komponent by om te onderhou.

Foute wat soos geloofsprobleme lyk

’n TLS-handdruk wat nooit voltooi nie, of ’n VERIFY ERROR: depth=0, error=certificate signature failure, is ’n vertrouensprobleem en gebeur voordat enige gebruikersnaam gelees word. ’n proto tcp-kliënt wat na ’n UDP-luisteraar wys, faal op dieselfde plek: die pakkette bereik nooit die verifikasiefase nie, so elke wagwoord lyk verkeerd by assosiasie. Hou sertifikaatverifikasie aan voordat die geloofsbrief gestuur word; ’n bekende opdrag sê niks oor wie die wagwoord ontvang nie. Kontroleer die sertifikaatketting, die algemene naam en die vervoer voordat jy die geloofsbrief aanraak.

Shell-foute in die script wat die profiel saamstel, is die ander valse leidraad. ’n Ontbrekende spasie binne [ ! -f "$file" ] lewer command not found, die script stop vroeg, die profiel word nooit herbou nie, en die kliënt begin met die vorige een. Daardie fout hoort by die shell, nie by verifikasie nie, en geen hoeveelheid hertik van die wagwoord sal dit uitwis nie.

Nie elke opdrag in hierdie vloei is hierdie geloofsbrief nie. ’n Privaat-sleutel-wagfrase, ’n HTTP-proxy-aanmelding en die dienswagwoord is drie verskillende geheime wat in verskillende fases gevra word, en ’n sleutelwagfrase word gewoonlik deur die kliënt of ’n agent hanteer eerder as deur auth-user-pass. As die opdrag verskyn voordat die TLS-sessie op is, beantwoord jy die verkeerde vraag en geen rekeningherstel sal help nie. Sodra die verkeerde opdrag uitgesluit is, begin die oorblywende kontroles by die vroegste laag:

• Lees die eerste protokolfout, nie die laaste geloofsbriefreël nie: TLS, dan verifikasie, dan push.
• Bevestig die lêer is twee reëls, het geen karretjie-terugkeer nie, en word deur ’n absolute pad verwys.
• Bevestig die profiel en die opdraglyn stem nie oor die riglyn nie.
• Skei "geloofsbriewe aanvaar" van "verkeer vloei" – roetering en DNS is ’n latere laag.

Sodra die kliënt die push-fase bereik, hou op om na geloofsbriewe te kyk en begin die roetes en DNS-bediener lees wat die bediener gestuur het. Dit is die volgende probleem, en dit het niks te doen met die wagwoord wat jy pas reggemaak het nie.