OpenVPN auth-user-pass: fail, stdin või küsimus? Kuidas valida

Kolme asja järgi otsustatakse, millist tunnuste allikat kasutada: kas inimene istub konsooli juures, kas saladus tohib kettale jääda ja kas mõni teine protsess peab küsimusele vastama. Kui valid vale, teatab klient stdin-probleemist, kuigi parool on täiesti kehtiv, mis saadab enamiku inimesi ilma põhjuseta serveri juurde. Valige esmalt tee; veateated on mõistlikud alles siis, kui teate, milline tee need tekitas.

Kolm tingimust, mis selle otsustavad

Konsooliküsimus on ainus tee, mis vajab inimest, seega ainus, mis systemd üksuses või konteineris vaikselt nurjub. Kui inimene käivitab kliendi ja sisestab parooli, ei osale ükski fail ja midagi tundlikku ei jõua kettale. Kui klient käivitub süsteemi alglaadimisel, muutub sama küsimus tõmbamiseks ja aegumine ilmneb tavaliselt üldise ühenduse tõrkena, mitte tunnuste veana.

Tunnustefail on õige vastus, kui protsess käivitub järelevalveta ja saladus tohib kettale jääda kontrollitud õiguste kogumi all. Kui saladust ei tohi üldse kirjutada - ainult hoidla poliitika, lühiajaline token - vajate voogu, mille klient saab avada, mis tähendab praktikas protsessi asendamist või abilist, mis kirjutab failideskriptorisse. Haldusliides katab neljanda juhtumi: kontroller, mis juba haldab tunnelielu tsüklit ja suudab küsimustele soketi kaudu vastata.

• Inimene konsooli juures, automatiseerimist pole: interaktiivne küsimus.
• Järelevalveta käivitus, saladust tohib salvestada: tunnustefail režiimiga 0600.
• Järelevalveta käivitus, saladust ei tohi salvestada: protsessi asendamine või fd, kuhu saladusagent kirjutab.
• Klienti omab teine protsess: haldusliides.

Kui sobib kaks vastust, eelistage seda, mis hoiab saladuse väljaspool argvi ja väljaspool shelli ajalugu. Programmi argumendina edastatud parool on protsesside nimekirja kaudu loetav igale kohalikule kasutajale ja seda paljastust on raske tagasi pöörata.

Mida iga sisendtee tegelikult teeb

--auth-user-pass üksi küsib konsoolil kasutajanime ja parooli. Failinime korral võtab klient esimese rea kasutajanimeks ja teise rea parooliks; miski ei toeta jutumärke, kommentaare ega võti-väärtus süntaksit. See ongi kogu vorming, seega igaüks, kes seda INI-faili lootes muudab, rikub selle. Reasisene <auth-user-pass> plokk hoiab samu kahte rida profiili sees, mis muudab profiili enda saladuseks ja asetab selle samasse käsitlemise klassi nagu privaatvõti.

Ülejäänud kaks teed on voog ja soket. OpenVPN vajab ainult loetavat failideskriptorit, seega aktsepteerib see protsessi asendamist, toruga toetatud /dev/fd kirjet või failinime, mis on tegelikult FIFO. Haldusliides on olemuselt erinev: klient küsib väärtusi järelevalveprotsessilt, mitte ei loe neid ise. See erinevus loeb uuesti ühendamisel: tunnustefail, FIFO, kuhu saladusabiline saab uuesti kirjutada, ja haldusliides saavad ilma inimeseta uuesti varustada; protsessi asendamine ei saa, sest deskriptor kulub esimesel lugemisel.

Fail peab olema täpselt kaks rida

Kaks tõrkerežiimi katavad enamiku katkistest tunnustefailidest. Windowsi redaktor jätab CRLF-lõpud, vankri tagastus muutub parooli osaks ja server lükkab tagasi väärtuse, mis ekraanil õige välja näeb. Tühi teine rida - tühi rida seal, kuhu parool kuulub - jätab kliendi tühja parooliga, mille server tagasi lükkab, ehkki väärtus ekraanil õige välja näeb. Täiendav reavahetus parooli järel on kahjutu. Kirjutage fail shellist, mitte redaktorist, ja kontrollige baite:

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

Tee on sama tähtis kui sisu. Suhteline tee lahendatakse protsessi töökataloogi suhtes, mis teenuse puhul on harva see kataloog, kus te katsetasite. Kasutage absoluutset teed, tehke fail selle konto omandiks, mis klienti käitab, ja hoidke režiimi 0600, et grupp ja teised ei saaks seda lugeda. OpenVPN 2.6 käsiraamat loetleb direktiivi aktsepteeritud vormid; kontrollige seda enne, kui mõtlete välja kolmanda.

Testige faili enne, kui süüdistate serverit. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 käivitamine trükib, kas fail avati ja hiljem, kas tunnused võeti vastu, mis ütleb, millist kihti järgmisena muuta.

Vood, stdin ja vead, mida need tekitavad

Parooli torusse panemine on esimene, mida enamik proovib, ja tee, kus on kõige rohkem üllatusi. Protsessi asendamine töötab, sest klient vajab ainult loetavat deskriptorit: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin edastamine töötab ainult siis, kui stdin on klienti küsimise hetkel veel avatud ja loetav, mis ei kehti torustikus, mis on selle juba ära tarbinud.

ERROR: could not read Auth username from stdin on kaks erinevat põhjust. Mõnel 2.3.x kliendil tuli teade stdin-käsitlemise defektist, mille hilisemad 2.3 väljaanded parandasid, seega nii vana klient paraneb ainult uuendamisega. Praegusel kliendil tähendab sama sõnastus, et klient küsis konsoolisisendit ja stdin ei olnud terminal - täpselt see olukord systemd üksuses, cron-töös või konteineris, mis käivitati ilma -t.

auth-nocache lisab kolmanda tsükli, mis näeb välja nagu katkine parool. See viskab tunnused pärast kasutamist mälust välja, seega võrgu muutusest põhjustatud uuestiühendusel pole midagi uuesti esitada ja küsimus naaseb. See on direktiiv, mis töötab nii, nagu projekteeritud. auth-nocache muudab seda, mida klient mälus hoiab, mitte seda, mida server või identiteedipakkuja kontost arvab, seega kogu parandus on sama faili uuesti varustamine, restardil uuesti loetuna - ja hallatava ühenduse puhul peaks see varustamine tulema heakskiidetud saladuste hoidlast, mitte skriptis olevast paroolist.

Haldusliides, kui küsimust omab teine protsess

Kontroller, mis juba jälgib tunnelit, saab vastata ka selle küsimustele. Käivitage klient --management 127.0.0.1 7505-ga, lugege olekuread ja jälgige >PASSWORD:Need 'Auth' username/password. Kontroller vastab username "Auth" alice-ga, millele järgneb password "Auth" ... eraldi käsuridadel. Token 'Auth' kordab päringu identifikaatorit ja peab klappima, muidu vastus eiratakse ja klient ootab.

Hind on olekumasin, mis on nüüd teie oma: ühenduste järjekord, kliendi restardid ja kohalik soket, milleni teised hosti kasutajad ei tohi jõuda. Selle eest saate käitusajal varustatud tunnuse, ilma failita kettal ja ilma küsimuseta, mis võib tõmbama jääda. Kui miski muu teie virnas juba protokolli ei räägi, lisab see tee hooldatava komponendi.

Tõrked, mis näivad tunnuste probleemidena

TLS-kätlus, mis ei lõpe kunagi, või VERIFY ERROR: depth=0, error=certificate signature failure on usaldusprobleem ja juhtub enne, kui ühtki kasutajanime loetakse. UDP-kuulajale suunatud proto tcp klient nurjub samas kohas: paketid ei jõua kunagi autentimise faasi, seega iga parool näib seostamise tõttu vale. Hoidke sertifikaadi kontroll sisse lülitatud enne tunnuse saatmist; tuttav küsimus ei ütle midagi selle kohta, kes parooli saab. Kontrollige sertifikaadiahelat, üldnime ja transporti enne, kui tunnust puudutate.

Shelli vead profiili kokku panevas skriptis on teine vale jälg. Puuduv tühik [ ! -f "$file" ] sees tekitab command not found, skript peatub vara, profiili ei ehita enam kunagi üles ja klient käivitub eelmisega. See viga kuulub shellile, mitte autentimisele, ja ükski parooli ümberkirjutamine ei kõrvalda seda.

Mitte iga küsimus selles voos ei ole see tunnus. Privaatvõtme paroolifraas, HTTP-puhverserveri sisselogimine ja teenuse parool on kolm erinevat saladust, mida küsitakse erinevates faasides, ja võtmefraasi käsitleb tavaliselt klient või agent, mitte auth-user-pass. Kui küsimus ilmub enne, kui TLS-sessioon on püsti, vastate vale küsimusele ja ükski konto lähtestamine ei aita. Kui vale küsimus on välistatud, algavad ülejäänud kontrollid kõige varasemast kihist:

• Lugege esimest protokolliviga, mitte viimast tunnuste rida: TLS, siis autentimine, siis push.
• Kinnitage, et fail on kaks rida, ei sisalda vankri tagastusi ja sellele viidatakse absoluutse teega.
• Kinnitage, et profiil ja käsurida ei ole direktiivi osas vastuolus.
• Eraldage "tunnused vastu võetud" ja "liiklus voolab" - marsruutimine ja DNS on hilisem kiht.

Kui klient jõuab push-faasi, lõpetage tunnuste vaatamine ja hakake lugema marsruute ja DNS-servereid, mille server saatis. See on järgmine probleem ja sellel pole midagi pistmist parooliga, mille just parandasite.