Shërbimi OpenVPN ndalon te kërkesa për fjalëkalimin e çelësit privat: si ta rregulloni

OpenVPN kërkon frazën e çelësit privat në makinën lokale, prandaj një skedar hyrjeje që funksionon nuk i përgjigjet kurrë. Në një shërbim nuk ka terminal për të shtypur, dhe nisja ose ngec ose dështon me një zë journal që emërton hyrjen dhe jo shkakun. Janë dy sekrete të përfshira, dhe secili ka nevojë për burimin e vet të lexueshëm përpara se unit të riniset. Rrjedha më poshtë i ndan ato, pastaj kontrollon identitetin që hap vërtet çdo skedar.

Dalloni dy kërkesat

Frazë e çelësit deshifron çelësin privat lokal; kredencialet e llogarisë vërtetojnë sesionin me serverin. Ato vijnë nga vende të ndryshme, dështojnë në momente të ndryshme dhe japin mesazhe të ndryshme. Ngatërrimi i tyre i dërgon njerëzit të kërkojnë rivendosje fjalëkalimi, ndërsa llogaria nuk ishte fare e përfshirë. Lexoni tekstin e kërkesës përpara se të ndryshoni çdo opsion, sepse formulimi është e vetmja e dhënë e besueshme se cili sekret mungon.

Në Community OpenVPN 2.x, askpass emërton një skedar që mban frazën e çelësit në rreshtin e parë, dhe auth-user-pass emërton një skedar me emrin e përdoruesit në një rresht dhe fjalëkalimin në rreshtin tjetër. Asnjëri skedar nuk mund të plotësojë opsionin tjetër. Një aplikacion desktopi ose një profil NetworkManager mund t'i mbajë të dy në depon e vet të sekreteve, të cilën një klient i linjës së komandës nuk e lexon kurrë, prandaj shënoni cilin klient po konfiguroni përpara se të shkruani çdo shteg.

Drejtoji të dy opsionet nga skedarë të lexueshëm

Një profil që ka nevojë për të dyja hyrjet përfundon me tre referenca skedarësh: çelësin e kriptuar, frazën që e hap dhe çiftin e hyrjes. Shtojini pa prekur CA-në ose kontrollet e identitetit, sepse ato vendosin kush është serveri dhe nuk janë pjesë e këtij problemi. Nëse vendosja nuk përdor fare kredenciale llogarie, shtimi i auth-user-pass krijon një hyrje që askush nuk mund ta sigurojë.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Opsionet pa argument sillen ndryshe nga opsionet me shteg, dhe në një shërbim ky ndryshim ka rëndësi. Një askpass pa argument lexon ende konsolën, dhe një skedar auth-user-pass me vetëm emrin e përdoruesit lë ende një kërkesë fjalëkalimi në pritje. Pasi klienti bëhet daemon, ai nuk mund t'i kërkojë fare një terminali hyrje, prandaj një shërbim i konfiguruar kështu nuk ngrihet.

Shtigjet absolute heqin pyetjen për drejtorinë e punës, por nuk japin akses. Më pas vijnë pronësia, modaliteti dhe kalimi, dhe të treja kontrollohen kundrejt llogarisë nën të cilën punon procesi.

Lexoni konfigurimin e unit përpara profilit

Është unit, jo skedari që po redaktonit, ai që vendos cilin konfigurim ngarkon instanca. Lexoni rreshtin e komandës dhe çdo drop-in, pastaj ndiqni drejtorinë e punës deri te profili që përdoret vërtet. Një referencë fraze e shtuar në një skedar .ovpn tjetër nuk ndryshon asgjë për këtë instancë.

Tre komanda vetëm-lexim u përgjigjen pjesës më të madhe. E para shtyp unit dhe çdo drop-in, e dyta identitetin dhe cilësimet e sandbox që lidhin procesin, dhe e treta për çfarë u ankua vërtet nisja e fundit. Përdorni emrin e instancës që ekziston në host:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Kushtojini vëmendje ProtectHome dhe opsioneve të vetë profilit user, group dhe chroot. Një skedar nën një drejtori shtëpie mund të jetë i lexueshëm në shell-in tuaj dhe i padukshëm brenda shërbimit kur drejtoritë e shtëpisë fshihen. Llogaria me të cilën nis systemd nuk është gjithmonë llogaria që hap në fund çelësin.

Provoni se identiteti i ekzekutimit mund të hapë të dy skedarët

Leximi i modalitetit nuk mjafton, sepse çdo drejtori në shteg duhet të jetë e kalueshme nga i njëjti identitet. Kaloni shtegun komponent pas komponenti, pastaj provoni hapjen si llogaria që përdor procesi. Një skedar me modalitet 600 në pronësi të root funksionon vetëm sa kohë procesi është ende root, gjë që nuk është e vërtetë pas uljes së privilegjeve që bëjnë shumë profile. Dy komanda mbulojnë kalimin dhe hapjen:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Komanda e parë shtyp modalitetin e çdo komponenti dhe dështon atje ku llogaria nuk mund të kalojë; e dyta përgjigjet pyetjes së vetme të rëndësishme, nëse identiteti i ekzekutimit mund ta hapë skedarin për lexim. Asnjëra nuk shtyp përmbajtjen e skedarit, dhe pikërisht kjo është pika kur skedari mban një frazë. Përsëritni testin për skedarin e hyrjes, sepse të dy shpesh ruhen me pronësi të ndryshme.

Nëse procesi përdor një chroot ose një namespace të kufizuar, ekzekutoni të njëjtin test nga brenda atij pamjeje, përndryshe përgjigjja përshkruan sistemin e gabuar të skedarëve. Një frazë e ruajtur nën një drejtori shtëpie të fshehur është shembulli i zakonshëm i një testi që kalon jashtë unit dhe dështon brenda tij.

Kontrolloni nisjen e parë, pastaj një rilidhje

Nisni instancën një herë dhe lexoni dështimin e parë, jo të fundit. Një skedar hyrjeje që mungon, një deshifrim çelësi i dështuar dhe një AUTH_FAILED nga serveri janë tre ngjarje të ndryshme me tre rregullime të ndryshme. Rregullimi i një paralajmërimi leje nuk provon asgjë për atë nëse çelësi u hap.

Rreshti i journal-it thotë cila nga të tre. Rregullimi rrjedh nga cila hyrje dështoi:

Pastaj provoni ciklin e jetës që ju nevojitet vërtet: nisje gjatë boot dhe çdo rilidhje e mbështetur, jo vetëm nisje manuale nga shell-i juaj. Me auth-nocache hyrjet hidhen pas përdorimit të parë, prandaj një rilidhje e mëvonshme ka ende nevojë për një burim të lexueshëm. Një varg çelësash që hapet në hyrjen e desktopit nuk është i disponueshëm për një shërbim që nisi përpara se dikush të hynte, dhe kjo është arsyeja e zakonshme pse një test manual kalon dhe një rinisje dështon. Nëse nisja e parë ka sukses dhe një rilidhje e mëvonshme dështon, lexoni journal-in për ngjarjen e rilidhjes përpara se të ndryshoni përsëri lejet.

Ruajtja e frazës pranë çelësit zvogëlon atë që ju jep kriptimi, prandaj kufizoni atë skedar dhe kopjet e tij. Trajtojeni heqjen e frazës së çelësit si një vendim të veçantë kredencialesh, jo si rregullimin për një hyrje që mungon. Një vendosje që varet nga miratimi njerëzor ose MFA interaktive ka nevojë për agjentin ose integrimin e menaxhimit të mbështetur; një kod njëpërdorimësh i ruajtur përgjithmonë nuk është zëvendësim ekuivalent.