Korjaus: OpenVPN ei voinut lukea Auth-käyttäjänimeä vakiosyötteestä

could not read Auth username from stdin näyttää todennusongelmalta eikä ole sitä. OpenVPN yritti kysyä käyttäjänimeä vakiosyötteestä, ei löytänyt mitään luettavaa ja pysähtyi ennen kuin se edes otti yhteyttä palvelimeen. Tili voi olla täysin kelvollinen; prosessilla ei yksinkertaisesti ole ketään kysyttävää.

Siksi ensimmäinen hyödyllinen vaihe on varmistaa, mitä asiakas lukee, ei yrittää yhteyttä uudelleen tai muuttaa palvelinpuolen asetuksia. Käy alla olevat tarkistukset järjestyksessä läpi ja pysähdy ensimmäiseen, joka epäonnistuu.

Lue virhe paikallisena syöttövirheenä

Kun auth-user-pass esiintyy ilman tiedostoargumenttia, asiakas odottaa kysyvänsä. Interaktiivisessa kuoressa se kysymys toimii, koska prosessilla on pääte. systemd:n, cron-työn tai kontin alla vakiosyöte on yleensä tyhjä, ja luku palaa heti virheellä, jonka näet.

Viesti nimeää myös kentän, joka epäonnistui, käyttäjänimen tai salasanan, mikä kertoo, kuinka pitkälle luku ehti. Puuttuva käyttäjänimi tarkoittaa, ettei prosessi voinut lukea yhtään mitään. Puuttuva salasana onnistuneen käyttäjänimen jälkeen tarkoittaa, että syöttövirta päättyi kahden luvun välissä, mikä on tyypillistä puoliksi kirjoitetulle tiedostolle tai suljetulle putkelle.

Varmista asiakkaan oma näkemys ennen kuin muutat mitään muuta. Aja se etualalla samalla kokoonpanolla ja samalla käyttäjällä ja seuraa, ilmestyykö kysymys. Jos se ilmestyy kuoressasi mutta ei palvelunhallinnan alla, ero on syöttölähteessä, ei tunnistetiedoissa. Nopea vertailu unit-tiedoston ja kuoresi ympäristön välillä näyttää yleensä, kumpi tarjoaa päätteen.

Anna palvelulle tuettu tunnistetietojen lähde

Tuettu valvomaton lähde on tunnistetiedosto, joka annetaan argumenttina komennolle auth-user-pass. Tiedosto luetaan pelkkänä tekstinä: ensimmäinen rivi on käyttäjänimi, toinen on salasana. Osoita siihen absoluuttisella polulla, esimerkiksi /etc/openvpn/client/creds , jotta palvelutilin työhakemisto ei voi muuttaa direktiivin merkitystä.

Käyttöoikeudet ovat yhtä tärkeitä kuin polku. Tiedoston on oltava luettavissa siltä tililtä, joka ajaa asiakasta, eikä kaikilta muilta, ja sen tulisi kuulua palvelutilille tai rootille ryhmän kanssa, joka sisältää palvelun. Tarkista luettavuus kyseisenä tilinä tulostamatta sisältöä.

Suhteellinen polku on hiljainen epäonnistumistila. Profiili voi olla yhdessä hakemistossa, kun taas systemd käynnistää prosessin jossain muualla, joten tiedosto, joka ratkeaa kuoressasi, ei ratkea palvelulle. Siirrä tunnistetiedot kiinteään paikkaan ja viittaa niihin absoluuttisesti. Käynnistä sitten palvelu kerran ja varmista, että samaa polkua käytetään, sen sijaan että luottaisit profiilieditorin näkymään.

Jos käyttöönotto vaatii kertakäyttökoodin tai muun interaktiivisen haasteen, päätä, tukeeko asiakkaan työnkulku sitä todella valvomatta. Tiedosto, jossa on staattinen salasana, ei voi vastata pyörivään koodiin, ja vastaamattoman kysymyksen uudelleen yrittäminen ei lisää tietoa.

Miksi script-security ei auta

script-security säätelee, saako asiakas suorittaa skriptejä ja kuinka paljon se saa välittää niille, mukaan lukien sen, voidaanko salasana antaa skriptille ympäristömuuttujan kautta. Se ei kerro mitään siitä, mistä käyttäjänimi ja salasana alun perin tulevat.

Sen nostaminen korkeammalle tasolle on tavallinen refleksi, koska viesti mainitsee Authin, mutta se muuttaa skriptien käyttöoikeuksia eikä syöttölähdettä, ja laajentaa sitä, mitä asiakas saa suorittaa. Jos apuskripti on osa suunnittelua, korjaa ensin syöttölähde ja pidä suojaustaso alimmassa arvossa, jonka käyttöönotto tarvitsee.

Hallintaliittymä on laillinen vaihtoehto. Front end voi yhdistää siihen, vastaanottaa tunnistetietopyynnön ja vastata käyttäjänimellä ja salasanalla, näin jotkin GUI:t toimivat. Jos käytät sitä, sido se paikalliseen osoitteeseen, suojaa se hallintasalasanatiedostolla ja rajoita, kuka voi yhdistää, koska se on asiakkaan ohjauskanava.

Varmista seuraava vaihe, kun asiakas on lukenut tiedoston

Kun asiakas voi lukea tunnistetiedot, seuraava virhe on todellinen vaihto palvelimen kanssa, ja sen viestillä on eri merkitys. Todennusvirhe siinä vaiheessa tarkoittaa, että palvelin hylkäsi tilin; haastevastaus tarkoittaa, että palvelin haluaa toisen tekijän. Käsittele niitä uusina ongelmina, älä saman toistona.

Testaa koko polku niin kuin palvelu sen ajaa: sama tili, sama työhakemisto, sama unit-ympäristö. Yhteys, joka toimii vain kuorestasi käynnistettynä, on merkki siitä, että ympäristömuuttuja tai pääte on yhä osa virtaa.

Pidä sitten salaisuudet siellä, minne ne kuuluvat. Komentoriviargumenttien salasanat näkyvät prosessitaulukossa, ja virheenkorjaustulosteen salasanat päätyvät tiketteihin. Käytä suojattua tiedostoa tai hallintaliittymää, pidä lokit tasolla, joka ei toista tunnistetietoja, ja vaihda tiedosto, kun joku pääsyn omaava lähtee.

Tarkistuslista: absoluuttinen tunnistetietojen polku, luettavissa palvelutilinä, päätettä ei tarvita, script-security jätetty minimiin, hallintaliittymä vain jos se on sidottu ja todennettu, ja tuloksena oleva palvelinvastaus käsitellään erillisenä tapahtumana.