OpenVPN auth-user-pass: triem, stdin of frege? Hoe te kiezen

Trije dingen bepale hokker bewiisboarne jo brûke moatte: oft der in persoan by de konsola sit, oft it geheim op ’e skiif libje mei, en oft in oar proses de frege beantwurdzje moat. Kies ferkeard en de kliïnt meldt in stdin-probleem wylst it wachtwurd folslein jildich is, en dat stjoert de measte minsken sûnder reden nei de tsjinner. Kies earst it paad; de flaterberjochten hawwe pas sin as jo witte hokker paad se makke hat.

De trije betingsten dy’t it beslisse

De konsolfrege is it iennige paad dat in minske nedich hat, dus it iennige dat stilwei mislearret yn in systemd-ienheid of in kontener. As in persoan de kliïnt start en it wachtwurd yntypet, binne der gjin triemmen by belutsen en komt der neat gefoelichs op ’e skiif. As de kliïnt by it opstarten start, wurdt deselde frege in hinge, en de tiidlimit ferskynt meastentiids as in algemiene ferbiningflater ynstee fan in bewiisflater.

In bewiisbestân is it goede antwurd as it proses sûnder tafersjoch start en it geheim op ’e skiif oerlibje mei ûnder in kontrolearre set tastimmingen. As it geheim hielendal net skreaun wurde mei - in belied fan allinnich de klûs, in koartlibjend token - hawwe jo in stream nedich dy’t de kliïnt iepenje kin, wat yn ’e praktyk prosesferfanging of in helper betsjut dy’t yn in triemdeskriptor skriuwt. De behearinterface dekt it fjirde gefal: in kontrôler dy’t al de libbenssyklus fan ’e tunnel beheart en fragen oer in socket beantwurdzje kin.

• Minsk by de konsola, gjin automatisearring: ynteraktive frege.
• Start sûnder tafersjoch, geheim mei bewarre wurde: bewiisbestân mei modus 0600.
• Start sûnder tafersjoch, geheim mei net bewarre wurde: prosesferfanging of in fd dêr’t in geheimagint yn skriuwt.
• In oar proses hat de kliïnt: behearinterface.

As twa antwurden passe, kies dan dy’t it geheim bûten argv en bûten de shellskiednis hâldt. In wachtwurd dat as programma-argumint trochjûn wurdt, is troch elke lokale brûker lêsber fia de prosesslist, en dy bleatstelling is dreech werom te draaien.

Wat elk ynfierpaad eins docht

--auth-user-pass op himsels freget om in brûkersnamme en in wachtwurd by de konsola. Mei in triemnamme nimt de kliïnt rigel ien as de brûkersnamme en rigel twa as it wachtwurd; neat stipet oanhelling, kommentaar of kaai-wearde-syntaksis. Dat is it hiele formaat, dus elkenien dy’t it bewurket yn ’e ferwachting fan in INI-triem brekt it. In ynline <auth-user-pass>-blok hâldt deselde twa rigels yn it profyl, wat it profyl sels in geheim makket en it yn deselde behannelingsklasse as in priveekaai pleatst.

De oare twa paden binne in stream en in socket. OpenVPN hat allinnich in lêsbere triemdeskriptor nedich, dus it akseptearret in prosesferfanging, in troch in piip stipe /dev/fd-yngong of in triemnamme dy’t eins in FIFO is. De behearinterface is oars fan aard: de kliïnt freget in tafersjochproses om de wearden ynstee dat er se sels lêst. Dat ferskil is wichtich by opnij ferbinen: in bewiisbestân, in FIFO dêr’t in geheimhelper wer yn skriuwe kin, en de behearinterface kinne sûnder minske opnij leverje; prosesferfanging kin dat net, om’t de deskriptor by de earste lêzing ferbrûkt wurdt.

De triem moat krekt twa rigels wêze

Twa flatermodi dekke de measte brutsen bewiisbestannen. In Windows-bewurker lit CRLF-einen stean, de weinrichter komt yn it wachtwurd telâne, en de tsjinner wiist in wearde ôf dy’t op it skerm goed liket. In lege twadde rigel - in lege rigel dêr’t it wachtwurd hearre moat - lit de kliïnt mei in leech wachtwurd, dat de tsjinner ôfwiist ek al liket de wearde op it skerm goed. In ekstra nije rigel nei it wachtwurd is ûnskeadlik. Skriuw de triem út ’e shell, net út in bewurker, en kontrolearje de bytes:

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

It paad is like wichtich as de ynhâld. In relatyf paad wurdt oplost tsjin ’e wurkmap fan it proses, dy’t foar in tsjinst selden de map is dêr’t jo teste hawwe. Brûk in absolút paad, meitsje de triem eigen oan it akkount dat de kliïnt docht, en hâld modus 0600 sadat groep en oaren it net lêze kinne. De hânlieding fan OpenVPN 2.6 listet de akseptearre foarmen fan ’e rjochtline; kontrolearje dy foardat jo in tredde betinke.

Test de triem foardat jo de tsjinner de skuld jouwe. It draaien fan openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 prints oft de triem iepene is en, letter, oft de bewizen akseptearre binne, wat jo seit hokker laach jo folgjende feroarje moatte.

Streams, stdin en de flaters dy’t se jouwe

It wachtwurd troch piip ynfiere is it earste dat de measte minsken besykje en it paad mei de measte ferrassingen. Prosesferfanging wurket om’t de kliïnt allinnich in lêsbere deskriptor nedich hat: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin trochjaan wurket allinnich as stdin noch iepen en lêsber is op it stuit dat de kliïnt freget, wat net wier is yn in piip dy’t it al ferbrûkt hat.

ERROR: could not read Auth username from stdin hat twa ferskate oarsaken. By guon 2.3.x-kliïnten kaam it berjocht fan in stdin-behannelingsfout dy’t lettere 2.3-frijgaven reparearren, dus sa’n âlde kliïnt betteret allinnich troch te upgrade. By in aktuele kliïnt betsjut deselde wurden dat de kliïnt konsolynfier frege en stdin gjin terminal wie - krekt de situaasje yn in systemd-ienheid, in cron-taak of in kontener dy’t sûnder -t start is.

auth-nocache foeget in tredde lus ta dy’t op in brutsen wachtwurd liket. It smyt de bewizen nei gebrûk út it ûnthâld, dus in opnij ferbining troch in netwurkferoaring hat neat om wer te spyljen en de frege komt werom. Dat is de rjochtline dy’t wurket sa’t er ûntwurpen is. auth-nocache feroaret wat de kliïnt yn it ûnthâld hâldt, net wat de tsjinner of de identiteitsoanbieder fan it akkount tinkt, dus de hiele reparaasje is deselde triem opnij leverje, by in werstart opnij lêzen - en foar in beheard ferbining moat dy levering út ’e goedkarde geheimopslach komme, net in wachtwurd yn in skript.

De behearinterface as in oar proses de frege hat

In kontrôler dy’t de tunnel al tafersjoch hâldt, kin ek syn fragen beantwurdzje. Start de kliïnt mei --management 127.0.0.1 7505, lês de tastânrigels en let op >PASSWORD:Need 'Auth' username/password. De kontrôler antwurdet mei username "Auth" alice folge troch password "Auth" ... op aparte kommandorigels. It 'Auth'-token werhellet de identifikaasje út it fersyk en moat oerienkomme, oars wurdt it antwurd negearre en wachtet de kliïnt.

De kosten binne in tastânmasine dy’t jo no hawwe: ferbiningsfolchoarder, werstarts fan de kliïnt en in lokale socket dy’t oare brûkers op ’e host net berikke meie. Wat jo keapje is in bewiis dat by runtime levere wurdt, sûnder triem op ’e skiif en sûnder frege dy’t hingje kin. As neat oars yn jo stapel de protokol al praat, foeget dit paad in komponint ta om te ûnderhâlden.

Mislukkings dy’t op bewiisproblemen lykje

In TLS-hânskodding dy’t nea klear komt, of in VERIFY ERROR: depth=0, error=certificate signature failure, is in fertrouwensprobleem en bart foardat der in brûkersnamme lêzen wurdt. In proto tcp-kliïnt rjochte op in UDP-harker mislearret op itselde plak: de pakketten berikke nea de autentikaasjefaze, dus elk wachtwurd liket ferkeard troch assosjaasje. Hâld de sertifikaatferifikaasje oan foardat it bewiis ferstjoerd wurdt; in fertroude frege seit neat oer wa’t it wachtwurd krijt. Kontrolearje de sertifikaatkeatling, de mienskiplike namme en it ferfier foardat jo it bewiis oanreitsje.

Shellflaters yn it skript dat it profyl gearstalt binne it oare falske spoar. In ûntbrekkende spaasje yn [ ! -f "$file" ] produsearret command not found, it skript stoppet betiid, it profyl wurdt nea wer opboud en de kliïnt start mei it foarige. Dy flater heart by de shell, net by autentikaasje, en gjin inkel oerntypen fan it wachtwurd sil him weilûke.

Net elke frege yn dizze stream is dit bewiis. In wachtfrase foar in priveekaai, in HTTP-proxy-oanmelding en it wachtwurd fan ’e tsjinst binne trije ferskate geheim dy’t yn ferskate fazen frege wurde, en in kaaiwachtfrase wurdt meast troch de kliïnt of in agint behannele ynstee fan auth-user-pass. As de frege ferskynt foardat de TLS-sesje stiet, beantwurdzje jo de ferkearde fraach en gjin akkountwerstel sil helpe. As de ferkearde frege útsletten is, begjinne de oerbleaune kontrôles by de ierste laach:

• Lês de earste protokolflater, net de lêste bewiisrigel: TLS, dan autentikaasje, dan push.
• Befêstigje dat de triem twa rigels is, gjin weinrichters hat en troch in absolút paad oanwiisd wurdt.
• Befêstigje dat it profyl en de kommandorigel it net iens binne oer de rjochtline.
• Skied "bewizen akseptearre" fan "ferkear streamt" - routing en DNS binne in lettere laach.

As de kliïnt de push-faze berikt, stopje dan mei it besjen fan bewizen en begjin de rûtes en DNS-tsjinners te lêzen dy’t de tsjinner stjoerd hat. Dat is it folgjende probleem, en it hat neat te meitsjen mei it wachtwurd dat jo krekt reparearre hawwe.