Rregullim: OpenVPN nuk mundi të lexojë emrin e përdoruesit Auth nga hyrja standarde

could not read Auth username from stdin duket si problem vërtetimi dhe nuk është. OpenVPN u përpoq të kërkojë emrin e përdoruesit nga hyrja standarde, nuk gjeti asgjë të lexueshme dhe u ndal përpara se të kontaktonte ndonjëherë serverin. Llogaria mund të jetë plotësisht e vlefshme; procesi thjesht nuk ka kë të pyesë.

Prandaj hapi i parë i dobishëm është të konfirmoni çfarë lexon klienti, jo të riprovoni lidhjen ose të ndryshoni cilësimet në anën e serverit. Kaloni kontrollet më poshtë me radhë dhe ndaloni në të parën që dështon.

Lexojeni gabimin si dështim lokal i hyrjes

Kur auth-user-pass shfaqet pa një argument skedari, klienti pret të pyesë. Në një shell interaktiv ai prompt funksionon sepse procesi zotëron një terminal. Nën systemd, një punë cron ose një kontejner, hyrja standarde është zakonisht bosh dhe leximi kthehet menjëherë me gabimin që po shihni.

Mesazhi emërton gjithashtu fushën që dështoi, emrin e përdoruesit ose fjalëkalimin, gjë që tregon sa larg shkoi leximi. Mungesa e emrit të përdoruesit do të thotë që procesi nuk mundi të lexojë asgjë. Mungesa e fjalëkalimit pas një emri të përdoruesit të suksesshëm do të thotë që rryma e hyrjes mbaroi midis dy leximeve, gjë tipike për një skedar gjysmë të shkruar ose një tub të mbyllur.

Konfirmoni pikëpamjen e vetë klientit përpara se të ndryshoni diçka tjetër. Ekzekutoni atë në plan të parë me të njëjtin konfigurim dhe të njëjtin përdorues, dhe vëzhgoni nëse shfaqet kërkesa. Nëse shfaqet në shell-in tuaj por jo nën menaxherin e shërbimit, ndryshimi është burimi i hyrjes, jo kredencialet. Një krahasim i shpejtë i skedarit unit dhe mjedisit të shell-it tuaj zakonisht tregon cili prej tyre siguron një terminal.

Jepini shërbimit një burim të mbështetur kredencialesh

Burimi i mbështetur për funksionim pa mbikëqyrje është një skedar kredencialesh i kaluar si argument auth-user-pass. Skedari lexohet si tekst i thjeshtë: rreshti i parë është emri i përdoruesit, i dyti është fjalëkalimi. Tregoni drejt tij me një shteg absolut si /etc/openvpn/client/creds , në mënyrë që drejtoria e punës e llogarisë së shërbimit të mos mund të ndryshojë kuptimin e direktivës.

Lejet kanë po aq rëndësi sa shtegu. Skedari duhet të jetë i lexueshëm nga llogaria që ekzekuton klientin dhe jo nga të gjithë të tjerët, dhe duhet të jetë në pronësi të llogarisë së shërbimit ose të root me një grup që përfshin shërbimin. Kontrolloni lexueshmërinë si ajo llogari, pa shtypur përmbajtjen.

Një shteg relativ është mënyra e dështimit të heshtur. Profili mund të jetë në një drejtori ndërsa systemd e nis procesin diku tjetër, kështu që një skedar që zgjidhet në shell-in tuaj nuk zgjidhet për shërbimin. Zhvendosni kredencialet në një vend fiks dhe referojuni atyre në mënyrë absolute. Pastaj nisni shërbimin një herë dhe konfirmoni që përdoret i njëjti shteg, në vend që të mbështeteni te pamja e redaktuesit të profilit.

Nëse vendosja kërkon një kod njëpërdorimësh ose një sfidë tjetër interaktive, vendosni nëse rrjedha e punës e klientit e mbështet vërtet pa mbikëqyrje. Një skedar me fjalëkalim statik nuk mund t'i përgjigjet një kodi që rrotullohet, dhe riprovimi i një kërkese pa përgjigje nuk shton informacion.

Pse script-security nuk do të ndihmojë

script-security kontrollon nëse klienti mund të ekzekutojë skripte dhe sa mund t'u kalojë atyre, duke përfshirë nëse një fjalëkalim mund t'i jepet një skripti përmes një ndryshoreje mjedisi. Nuk thotë asgjë për nga vijnë fillimisht emri i përdoruesit dhe fjalëkalimi.

Ngritja e tij në një nivel më të lartë është një refleks i zakonshëm sepse mesazhi përmend Auth, por ndryshon lejet e skripteve, jo burimin e hyrjes, dhe zgjeron atë që klienti mund të ekzekutojë. Nëse një skript ndihmës është pjesë e dizajnit, rregulloni së pari burimin e hyrjes dhe mbajeni nivelin e sigurisë në vlerën më të ulët që i duhet vendosjes.

Ndërfaqja e menaxhimit është një alternativë legjitime. Një frontend mund të lidhet me të, të marrë kërkesën për kredenciale dhe të përgjigjet me emrin e përdoruesit dhe fjalëkalimin, kështu funksionojnë disa GUI. Nëse e përdorni, lidheni me një adresë lokale, mbroni me një skedar fjalëkalimi menaxhimi dhe kufizoni kush mund të lidhet, sepse është një kanal kontrolli për klientin.

Verifikoni fazën tjetër pasi klienti të lexojë skedarin

Pasi klienti mund të lexojë kredencialet, dështimi tjetër është një shkëmbim i vërtetë me serverin, dhe mesazhi i tij ka kuptim tjetër. Një dështim vërtetimi në atë fazë do të thotë që serveri refuzoi llogarinë; një përgjigje sfide do të thotë që serveri dëshiron një faktor tjetër. Trajtojini si probleme të reja dhe jo si i njëjti i përsëritur.

Testoni të gjithë rrugën ashtu siç do ta ekzekutojë shërbimi: i njëjti llogari, e njëjta drejtori pune, i njëjti mjedis unit. Një lidhje që funksionon vetëm kur niset nga shell-i juaj është shenjë se një ndryshore mjedisi ose një terminal është ende pjesë e rrjedhës.

Pastaj mbani sekretet aty ku duhet. Fjalëkalimet në argumentet e rreshtit të komandës shfaqen në tabelën e proceseve, dhe fjalëkalimet në daljen e korrigjimit përfundojnë në bileta. Përdorni një skedar të mbrojtur ose ndërfaqen e menaxhimit, mbani regjistrat në një nivel që nuk përsërit kredenciale, dhe ndërroni skedarin kur largohet kushdo me akses.

Lista e kontrollit: shteg absolut i kredencialeve, i lexueshëm si llogari shërbimi, pa nevojë për terminal, script-security i lënë në minimum, ndërfaqja e menaxhimit vetëm nëse është lidhur dhe vërtetuar, dhe përgjigja e serverit që rezulton trajtohet si ngjarje e veçantë.