OpenVPN auth-user-pass: tiedosto, stdin vai kehote? Näin valitset

Kolme asiaa ratkaisee, mitä tunnistelähdettä kannattaa käyttää: istuuko konsolilla ihminen, saako salaisuus elää levyllä ja täytyykö toisen prosessin vastata kehotteeseen. Jos valitset väärin, asiakas ilmoittaa stdin-ongelmasta vaikka salasana on täysin kelvollinen, ja se lähettää useimmat palvelimelle ilman syytä. Valitse polku ensin; virheilmoitukset ovat mielekkäitä vasta kun tiedät, mikä polku ne tuotti.

Kolme ehtoa, jotka ratkaisevat asian

Konsolin kehote on ainoa polku, joka tarvitsee ihmisen, joten se on ainoa, joka epäonnistuu hiljaisesti systemd-yksikössä tai kontissa. Jos ihminen käynnistää asiakkaan ja kirjoittaa salasanan, mikään tiedosto ei ole mukana eikä mitään arkaluontoista päädy levylle. Jos asiakas käynnistyy käynnistyksen yhteydessä, samasta kehotteesta tulee jumittuminen, ja aikakatkaisu näkyy yleensä yleisenä yhteysvirheenä eikä tunnistevirheenä.

Tunnistetiedostosto on oikea vastaus, kun prosessi käynnistyy ilman valvontaa ja salaisuus saa säilyä levyllä hallitun käyttöoikeusjoukon alla. Kun salaisuutta ei saa kirjoittaa lainkaan - vain holvi -käytäntö, lyhytikäinen token - tarvitset virran, jonka asiakas voi avata, mikä käytännössä tarkoittaa prosessin korvaamista tai apuria, joka kirjoittaa tiedostokuvaukseen. Hallintaliittymä kattaa neljännen tapauksen: ohjain, joka jo hallitsee tunnelin elinkaarta ja voi vastata kysymyksiin sockettiin.

• Ihminen konsolilla, ei automaatiota: interaktiivinen kehote.
• Valvomaton käynnistys, salaisuus saa tallentua: tunnistetiedostosto tilassa 0600.
• Valvomaton käynnistys, salaisuutta ei saa tallentaa: prosessin korvaaminen tai fd, johon salaisuusagentti kirjoittaa.
• Toinen prosessi omistaa asiakkaan: hallintaliittymä.

Kun kaksi vastausta sopii, valitse se, joka pitää salaisuuden poissa argvista ja shellin historiasta. Ohjelman argumenttina välitetty salasana on luettavissa jokaiselle paikalliselle käyttäjälle prosessiluettelon kautta, ja sitä paljastusta on vaikea perua.

Mitä kukin syöttöpolku todella tekee

--auth-user-pass yksinään kysyy käyttäjätunnuksen ja salasanan konsolilla. Tiedostonimen saatuaan asiakas ottaa ensimmäisen rivin käyttäjätunnukseksi ja toisen rivin salasanaksi; mikään ei tue lainausmerkkejä, kommentteja tai avain-arvo-syntaksia. Siinä on koko muoto, joten jokainen, joka muokkaa sitä INI-tiedostoa odottaen, rikkoo sen. Rivinsisäinen <auth-user-pass>-lohko sisältää samat kaksi riviä profiilissa, mikä tekee profiilista itsestään salaisuuden ja asettaa sen samaan käsittelyluokkaan kuin yksityinen avain.

Kaksi muuta polkua ovat virta ja socketti. OpenVPN tarvitsee vain luettavan tiedostokuvauksen, joten se hyväksyy prosessin korvaamisen, putkella tuetun /dev/fd-merkinnän tai tiedostonimen, joka on todella FIFO. Hallintaliittymä on luonteeltaan erilainen: asiakas kysyy arvot valvovalta prosessilta sen sijaan että lukisi ne itse. Tämä ero merkitsee uudelleenyhdistämisessä: tunnistetiedostosto, FIFO, johon salaisuusapuri voi kirjoittaa uudelleen, ja hallintaliittymä voivat toimittaa uudelleen ilman ihmistä; prosessin korvaaminen ei voi, koska kuvaus kulutetaan ensimmäisellä lukukerralla.

Tiedostossa on oltava täsmälleen kaksi riviä

Kaksi vikatilaa kattaa useimmat rikkinäiset tunnistetiedostostot. Windowsin editori jättää CRLF-loput, vaununpalautuksesta tulee osa salasanaa ja palvelin hylkää arvon, joka näyttää ruudulla oikealta. Tyhjä toinen rivi - tyhjä rivi siinä, mihin salasana kuuluu - jättää asiakkaan tyhjällä salasanalla, jonka palvelin hylkää vaikka arvo ruudulla näyttää oikealta. Ylimääräinen rivinvaihto salasanan jälkeen on harmiton. Kirjoita tiedosto shellistä, älä editorista, ja tarkista tavut:

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

Polku on yhtä tärkeä kuin sisältö. Suhteellinen polku ratkaistaan prosessin työhakemistoa vasten, joka palvelun kohdalla on harvoin se hakemisto, jossa testasit. Käytä absoluuttista polkua, tee tiedostosta asiakasta ajavan tilin omaisuutta ja pidä tila 0600, jotta ryhmä ja muut eivät voi lukea sitä. OpenVPN 2.6 -käsikirja luettelee direktiivin hyväksytyt muodot; tarkista se ennen kuin keksit kolmannen.

Testaa tiedosto ennen kuin syytät palvelinta. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 suorittaminen tulostaa, avattiinko tiedosto ja myöhemmin, hyväksyttiinkö tunnisteet, mikä kertoo mihin kerrokseen seuraavaksi puuttua.

Virrat, stdin ja niiden tuottamat virheet

Salasanan putkittaminen on ensimmäinen, mitä useimmat kokeilevat, ja polku, jossa on eniten yllätyksiä. Prosessin korvaaminen toimii, koska asiakas tarvitsee vain luettavan kuvauksen: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin välittäminen toimii vain, kun stdin on vielä auki ja luettavissa sillä hetkellä kun asiakas kysyy, mikä ei pidä paikkaansa putkessa, joka on jo kuluttanut sen.

ERROR: could not read Auth username from stdin on kaksi eri syytä. Joillakin 2.3.x-asiakkailla viesti tuli stdin-käsittelyn virheestä, jonka myöhemmät 2.3-julkaisut korjasivat, joten niin vanha asiakas paranee vain päivittämällä. Nykyisellä asiakkaalla sama sanamuoto tarkoittaa, että asiakas pyysi konsolin syötettä eikä stdin ollut pääte - täsmälleen se tilanne systemd-yksikössä, cron-tehtävässä tai kontissa, joka käynnistettiin ilman -t.

auth-nocache lisää kolmannen silmukan, joka näyttää rikkinäiseltä salasanalta. Se pudottaa tunnisteet muistista käytön jälkeen, joten verkkoyhteyden muutoksen laukaisemalla uudelleenyhdistämisellä ei ole mitään toistettavaa ja kehote palaa. Tämä on direktiivi, joka toimii suunnitellusti. auth-nocache muuttaa sitä, mitä asiakas pitää muistissa, ei sitä, mitä palvelin tai identiteetintarjoaja ajattelee tilistä, joten koko korjaus on saman tiedoston toimittaminen uudelleen, uudelleenluettuna uudelleenkäynnistyksessä - ja hallitulle yhteydelle tämän toimituksen tulisi tulla hyväksytystä salaisuuksien varastosta, ei skriptissä olevasta salasanasta.

Hallintaliittymä, kun toinen prosessi omistaa kehotteen

Ohjain, joka jo valvoo tunnelia, voi myös vastata sen kysymyksiin. Käynnistä asiakas parametrilla --management 127.0.0.1 7505, lue tilan rivit ja seuraa >PASSWORD:Need 'Auth' username/password. Ohjain vastaa username "Auth" alice ja sen jälkeen password "Auth" ... erillisillä komentoriveillä. 'Auth'-token toistaa pyynnön tunnisteen ja sen on täsmättävä, muuten vastaus jätetään huomiotta ja asiakas odottaa.

Hinta on tilakone, joka on nyt sinulla: yhteyksien järjestys, asiakkaan uudelleenkäynnistykset ja paikallinen socketti, johon muut isäntäkoneen käyttäjät eivät saa päästä. Se, mitä ostat, on ajonaikaisesti toimitettu tunniste, ilman tiedostoa levyllä ja ilman kehotetta, joka voi jumittua. Jos mikään muu pinossasi ei jo puhu protokollaa, tämä polku lisää ylläpidettävän komponentin.

Epäonnistumiset, jotka näyttävät tunnisteongelmilta

TLS-kättely, joka ei koskaan valmistu, tai VERIFY ERROR: depth=0, error=certificate signature failure, on luottamusongelma ja tapahtuu ennen kuin mitään käyttäjätunnusta luetaan. UDP-kuuntelijaan osoitettu proto tcp-asiakas epäonnistuu samassa kohdassa: paketit eivät koskaan saavuta todennusvaihetta, joten jokainen salasana näyttää väärältä assosiaation vuoksi. Pidä varmenteen varmennus päällä ennen kuin tunniste lähetetään; tuttu kehote ei kerro mitään siitä, kuka salasanan vastaanottaa. Tarkista varmenteiden ketju, yleisnimi ja kuljetus ennen kuin kosket tunnisteeseen.

Profiilin kokoavan skriptin shell-virheet ovat toinen väärä johtolanka. Puuttuva välilyönti [ ! -f "$file" ] sisällä tuottaa command not found, skripti pysähtyy aikaisin, profiilia ei koskaan rakenneta uudelleen ja asiakas käynnistyy edellisellä. Se virhe kuuluu shellille, ei todennukselle, eikä salasanan uudelleenkirjoittaminen poista sitä.

Jokainen tämän kulun kehote ei ole tämä tunniste. Yksityisen avaimen salalause, HTTP-välityspalvelimen kirjautuminen ja palvelun salasana ovat kolme eri salaisuutta, joita kysytään eri vaiheissa, ja avaimen salalausetta käsittelee yleensä asiakas tai agentti, ei auth-user-pass. Jos kehote ilmestyy ennen kuin TLS-istunto on pystyssä, vastaat väärään kysymykseen eikä mikään tilin nollaus auta. Kun väärä kehote on suljettu pois, jäljellä olevat tarkistukset alkavat aikaisimmasta kerroksesta:

• Lue ensimmäinen protokollavirhe, älä viimeistä tunnisteriviä: TLS, sitten todennus, sitten push.
• Varmista, että tiedostossa on kaksi riviä, ei vaununpalautuksia ja että siihen viitataan absoluuttisella polulla.
• Varmista, että profiili ja komentorivi eivät ole eri mieltä direktiivistä.
• Erota "tunnisteet hyväksytty" ja "liikenne virtaa" - reititys ja DNS ovat myöhempi kerros.

Kun asiakas saavuttaa push-vaiheen, lopeta tunnisteiden katsominen ja ala lukea reittejä ja DNS-palvelimia, jotka palvelin lähetti. Se on seuraava ongelma, eikä sillä ole mitään tekemistä juuri korjaamasi salasanan kanssa.