Riparo: OpenVPN ne povis legi la Auth-uzantnomon el la norma enigo

could not read Auth username from stdin aspektas kiel aŭtentiga problemo kaj tute ne estas tia. OpenVPN provis peti la uzantnomon per la norma enigo, trovis nenion legeblan kaj haltis antaŭ ol ĝi eĉ kontaktis la servilon. La konto povas esti tute valida; simple la procezo havas neniun, kiun demandi.

Tial la unua utila paŝo estas konfirmi, kion la kliento legas, ne reprovi la konekton aŭ ŝanĝi agordojn de la servila flanko. Trapasu la subajn kontrolojn laŭ ordo kaj haltu ĉe la unua, kiu malsukcesas.

Legu la eraron kiel lokan enigan fiaskon

Kiam auth-user-pass aperas sen dosiera argumento, la kliento atendas demandon. En interaga ŝelo tiu demando funkcias, ĉar la procezo posedas terminalon. Sub systemd, cron-tasko aŭ ujo, la norma enigo kutime estas malplena, kaj la legado tuj revenas kun la eraro, kiun vi vidas.

La mesaĝo ankaŭ nomas la kampon, kiu malsukcesis, uzantnomo aŭ pasvorto, kio diras, kiom malproksimen la legado iris. Mankanta uzantnomo signifas, ke la procezo tute ne povis legi ion ajn. Mankanta pasvorto post sukcesa uzantnomo signifas, ke la eniga fluo finiĝis inter la du legadoj, kio estas tipa por duone skribita dosiero aŭ fermita unuopaĵo.

Konfirmu la propran vidpunkton de la kliento antaŭ ol ŝanĝi ion ajn alian. Rulu ĝin en la malfono kun la sama agordo kaj la sama uzanto kaj observu, ĉu la demando aperas. Se ĝi aperas en via ŝelo sed ne sub la serva administrilo, la diferenco estas la eniga fonto, ne la akreditiloj. Rapida komparo de la unuo-dosiero kaj de via ŝela medio kutime montras, kiu el ili liveras terminalon.

Donu al la servo subtenatan fonton de akreditiloj

La subtenata fonto por senhoma funkciado estas akreditila dosiero pasigita kiel argumento al auth-user-pass. La dosiero estas legata kiel simpla teksto: la unua linio estas la uzantnomo, la dua estas la pasvorto. Montru al ĝi per absoluta vojo, ekzemple /etc/openvpn/client/creds , por ke la labora dosierujo de la serva konto ne povu ŝanĝi la signifon de la direktivo.

Permesoj gravas same kiel la vojo. La dosiero devas esti legebla de la konto, kiu rulas la klienton, kaj ne de ĉiuj aliaj, kaj ĝi devus aparteni al la serva konto aŭ al root kun grupo, kiu inkluzivas la servon. Kontrolu legeblecon kiel tiu konto, sen presi la enhavon.

Relativa vojo estas la silenta fiaskmaniero. La profilo povas esti en unu dosierujo, dum systemd startigas la procezon aliloke, do dosiero, kiu solviĝas en via ŝelo, ne solviĝas por la servo. Movu la akreditilojn al fiksa loko kaj referencu ilin absolute. Poste startigu la servon unufoje kaj konfirmu, ke la sama vojo estas uzata, anstataŭ fidi la vidon de la profila redaktilo.

Se la deplojo postulas unufojan kodon aŭ alian interagan defion, decidu, ĉu la laborfluo de la kliento vere subtenas ĝin senhoma. Dosiero kun statika pasvorto ne povas respondi al rotacia kodo, kaj reprovi demandon ne respondeblan aldonas neniun informon.

Kial script-security ne helpos

script-security regas, ĉu la kliento rajtas ruli skriptojn kaj kiom ĝi rajtas transdoni al ili, inkluzive ĉu pasvorto povas esti transdonita al skripto per media variablo. Ĝi diras nenion pri tio, de kie la uzantnomo kaj la pasvorto venas komence.

Levi ĝin al pli alta nivelo estas ordinara reflekso, ĉar la mesaĝo mencias Auth, sed ĝi ŝanĝas skriptajn permesojn anstataŭ la enigan fonton kaj vastigas tion, kion la kliento rajtas plenumi. Se helposkripto estas parto de la dezajno, unue ripari la enigan fonton kaj teni la sekurecnivelon je la plej malalta valoro, kiun la deplojo bezonas.

La administra interfaco estas legitima alternativo. Frontaĵo povas konektiĝi al ĝi, ricevi la akreditilan peton kaj respondi per la uzantnomo kaj pasvorto, kiel funkcias iuj GUI-oj. Se vi uzas ĝin, ligu ĝin al loka adreso, protektu ĝin per administra pasvorta dosiero kaj limigu, kiu povas konektiĝi, ĉar ĝi estas regkanalo por la kliento.

Kontrolu la sekvan etapon post kiam la kliento legos la dosieron

Post kiam la kliento povas legi la akreditilojn, la sekva fiasko estas vera interŝanĝo kun la servilo, kaj ĝia mesaĝo havas alian signifon. Aŭtentiga fiasko en tiu etapo signifas, ke la servilo rifuzis la konton; defia respondo signifas, ke la servilo volas alian faktoron. Traktu ilin kiel novajn problemojn, ne kiel la saman ripetitan.

Testu la tutan vojon tiel, kiel la servo rulos ĝin: sama konto, sama labora dosierujo, sama unuomedio. Konekto, kiu funkcias nur kiam startigita el via ŝelo, estas signo, ke media variablo aŭ terminalo ankoraŭ estas parto de la fluo.

Poste tenu la sekretojn tie, kie ili apartenas. Pasvortoj en komandliniaj argumentoj aperas en la proceza tabelo, kaj pasvortoj en sencimiga eligo finiĝas en biletoj. Uzu protektitan dosieron aŭ la administran interfacon, tenu protokolojn je nivelo, kiu ne ripetas akreditilojn, kaj rotaciu la dosieron, kiam foriras iu ajn kun aliro.

Kontrollisto: absoluta akreditila vojo, legebla kiel serva konto, neniu terminalo necesa, script-security lasita je sia minimumo, administra interfaco nur se ligita kaj aŭtentigita, kaj la rezulta servila respondo traktata kiel aparta evento.