Regstelling: OpenVPN kon nie die Auth-gebruikersnaam uit standaardinvoer lees nie

could not read Auth username from stdin lyk soos 'n verifikasieprobleem en is nie een nie. OpenVPN het probeer om die gebruikersnaam op standaardinvoer te vra, niks leesbaars gevind nie en gestop voordat dit ooit die bediener gekontak het. Die rekening kan heeltemal geldig wees; die proses het eenvoudig niemand om te vra nie.

Daarom is die eerste nuttige stap om te bevestig wat die kliënt lees, nie om die verbinding weer te probeer of instellings aan die bedienerkant te verander nie. Werk die kontroles hieronder in volgorde deur en stop by die eerste een wat misluk.

Lees die fout as 'n plaaslike invoerfout

Wanneer auth-user-pass sonder 'n lêerargument verskyn, verwag die kliënt om 'n opdrag te gee. In 'n interaktiewe dop werk daardie opdrag omdat die proses 'n terminale besit. Onder systemd, 'n cron-taak of 'n houer is standaardinvoer gewoonlik leeg, en die lees gee dadelik terug met die fout wat jy sien.

Die boodskap noem ook die veld wat misluk het, gebruikersnaam of wagwoord, wat jou vertel hoe ver die lees gekom het. 'n Ontbrekende gebruikersnaam beteken die proses kon glad niks lees nie. 'n Ontbrekende wagwoord ná 'n suksesvolle gebruikersnaam beteken die invoerstroom het tussen die twee leesaksies geëindig, wat tipies is van 'n halfgeskrewe lêer of 'n pyp wat gesluit het.

Bevestig die kliënt se eie siening voordat jy iets anders verander. Hardloop dit in die voorgrond met dieselfde konfigurasie en dieselfde gebruiker, en kyk of die opdrag verskyn. As dit in jou dop verskyn maar nie onder die diensbestuurder nie, is die verskil die invoerbron, nie die geloofsbriewe nie. 'n Vinnige vergelyking van die eenheidslêer en jou dopomgewing wys gewoonlik watter een 'n terminale verskaf.

Gee die diens 'n ondersteunde bron van geloofsbriewe

Die ondersteunde onbewaakte bron is 'n geloofsbriewe-lêer wat as argument aan auth-user-pass gegee word. Die lêer word as gewone teks gelees: die eerste reël is die gebruikersnaam, die tweede is die wagwoord. Wys daarop met 'n absolute pad soos /etc/openvpn/client/creds sodat die diensrekening se werkmap nie die betekenis van die richtlijn kan verander nie.

Toestemmings maak net soveel saak soos die pad. Die lêer moet leesbaar wees vir die rekening wat die kliënt bestuur en nie vir almal anders nie, en dit moet besit word deur die diensrekening of deur root met 'n groep wat die diens insluit. Kontroleer leesbaarheid as daardie rekening, sonder om die inhoud te druk.

'n Relatiewe pad is die stille foutmodus. Die profiel kan in een gids sit terwyl systemd die proses elders begin, so 'n lêer wat in jou dop oplos, los nie vir die diens op nie. Skuif die geloofsbriewe na 'n vaste plek en verwys absoluut daarna. Begin dan die diens een keer en bevestig dat dieselfde pad gebruik word, eerder as om op die profielredigeerder se siening te vertrou.

As die ontplooiing 'n eenmalige kode of 'n ander interaktiewe uitdaging vereis, besluit of die kliënt se werkvloei dit werklik onbewaakt ondersteun. 'n Lêer met 'n statiese wagwoord kan nie 'n roterende kode antwoord nie, en om 'n onbeantwoordbare opdrag te herhaal voeg geen inligting by nie.

Waarom script-security nie sal help nie

script-security beheer of die kliënt skrifte mag uitvoer en hoeveel dit daaraan mag deurgee, insluitend of 'n wagwoord deur 'n omgewingsveranderlike aan 'n skrip gegee kan word. Dit het niks te sê oor waar die gebruikersnaam en wagwoord oorspronklik vandaan kom nie.

Om dit na 'n hoër vlak te verhoog is 'n algemene refleks omdat die boodskap Auth noem, maar dit verander skripregte eerder as die invoerbron, en dit verbreed wat die kliënt mag uitvoer. As 'n hulpskrip deel van die ontwerp is, maak eers die invoerbron reg en hou die sekuriteitsvlak op die laagste waarde wat die ontplooiing nodig het.

Die bestuurskoppelvlak is 'n geldige alternatief. 'n Voorkant kan daaraan koppel, die geloofsbriewe-versoek ontvang en met die gebruikersnaam en wagwoord antwoord, wat is hoe sommige GUI's werk. As jy dit gebruik, bind dit aan 'n plaaslike adres, beskerm dit met 'n bestuurswagwoordlêer en beperk wie kan koppel, want dit is 'n beheerkanaal vir die kliënt.

Verifieer die volgende stadium nadat die kliënt die lêer gelees het

Sodra die kliënt die geloofsbriewe kan lees, is die volgende fout 'n werklike uitruiling met die bediener, en sy boodskap het 'n ander betekenis. 'n Verifikasiefout op daardie stadium beteken die bediener het die rekening verwerp; 'n uitdagingsantwoord beteken die bediener wil 'n ander faktor hê. Behandel dit as nuwe probleme eerder as dieselfde een wat herhaal word.

Toets die hele pad soos die diens dit sal hardloop: dieselfde rekening, dieselfde werkmap, dieselfde eenheidsomgewing. 'n Verbinding wat net werk wanneer dit uit jou dop begin word, is 'n teken dat 'n omgewingsveranderlike of 'n terminale steeds deel van die vloei is.

Hou dan die geheime waar hulle hoort. Wagwoorde in opdragreël-argumente verskyn in die prosestabel, en wagwoorde in ontfoutuitset beland in kaartjies. Gebruik 'n beskermde lêer of die bestuurskoppelvlak, hou logboeke op 'n vlak wat nie geloofsbriewe weergee nie, en roteer die lêer wanneer iemand met toegang vertrek.

Kontrolelys: absolute geloofsbriewe-pad, leesbaar as die diensrekening, geen terminale nodig nie, script-security op sy minimum gelaat, bestuurskoppelvlak slegs as dit gebind en geverifieer is, en die gevolglike bedienerantwoord as 'n afsonderlike gebeurtenis behandel.