La OpenVPN-servo haltas ĉe la peto pri la pasfrazo de la privata ŝlosilo: kiel ripari

OpenVPN petas la pasfrazon de la privata ŝlosilo sur la loka maŝino, do funkcianta ensaluta dosiero neniam respondas ĝin. En servo ne estas terminalo por tajpi, kaj la starto aŭ pendas aŭ malsukcesas kun ĵurnala ero, kiu nomas la enigon anstataŭ la kaŭzon. Du sekretoj estas en ludo, kaj ĉiu bezonas sian propran legeblan fonton antaŭ ol la unuo restartiĝas. La paŝoj sube apartigas ilin, poste kontrolas la identecon, kiu efektive malfermas ĉiun dosieron.

Distingi la du petojn

La ŝlosila pasfrazo malĉifras la lokan privatan ŝlosilon; la kontaj legitimiloj aŭtentikigas la sesion al la servilo. Ili venas el malsamaj lokoj, malsukcesas en malsamaj momentoj kaj produktas malsamajn mesaĝojn. Konfuzi ilin sendas homojn serĉi pasvortan restarigon, kvankam la konto tute ne partoprenis. Legu la petan tekston antaŭ ol ŝanĝi ajnan opcion, ĉar la vortigo estas la sola fidinda signo pri tio, kiu sekreto mankas.

En Community OpenVPN 2.x askpass nomas dosieron, kiu tenas la ŝlosilan pasfrazon en sia unua linio, kaj auth-user-pass nomas dosieron kun la uzantnomo en unu linio kaj la pasvorto en la sekva. Neniu dosiero povas kontentigi la alian opcion. Labortabla aplikaĵo aŭ NetworkManager-profilo povas teni ambaŭ en sia propra sekreta konservejo, kiun komandlinia kliento neniam legas, do notu, kiun klienton vi agordas antaŭ ol skribi ajnan vojon.

Direktu ambaŭ opciojn al legeblaj dosieroj

Profilo, kiu bezonas ambaŭ enigojn, finiĝas kun tri dosieraj referencoj: la ĉifrita ŝlosilo, la pasfrazo, kiu malŝlosas ĝin, kaj la ensaluta paro. Aldonu ilin sen tuŝi la CA aŭ la identeckontrolojn, ĉar tiuj decidas, kiu estas la servilo, kaj ne apartenas al ĉi tiu problemo. Se la deplojo tute ne uzas kontajn legitimilojn, auth-user-pass kreas enigon, kiun neniu povas liveri.

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

Nudaj opcioj kondutas malsame ol opcioj kun vojoj, kaj la diferenco gravas en servo. askpass sen argumento ankoraŭ legas la konzolon, kaj auth-user-pass-dosiero kun nur uzantnomo ankoraŭ lasas pasvortan peton atendantan. Post kiam la kliento demoniĝas, ĝi tute ne povas peti enigon de terminalo, do servo agordita tiel ne ekfunkcias.

Absolutaj vojoj forigas la demandon pri la labordosierujo, sed ne donas aliron. Posedo, modo kaj trapaso sekvas, kaj ĉiuj tri estas kontrolataj kontraŭ la konto, sub kiu la procezo ruliĝas.

Legu la agordon de la unuo antaŭ la profilo

Kiun agordon la instanco ŝargas decidas la unuo, ne la dosiero, kiun vi redaktis. Legu ĝian komandlinion kaj ĉiujn drop-in-ojn, poste sekvu la labordosierujon al la profilo, kiu efektive uziĝas. Pasfraza referenco aldonita al alia .ovpn-dosiero ŝanĝas nenion por ĉi tiu instanco.

Tri nurlegaj komandoj respondas la plejparton. La unua presas la unuon kaj ĉiujn drop-in-ojn, la dua presas la identecon kaj la sablujan agordojn, kiuj limigas la procezon, kaj la tria presas, pri kio la lasta starto efektive plendis. Uzu la instancan nomon, kiu ekzistas sur la gastiganto:

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

Atentu ProtectHome kaj la proprajn opciojn de la profilo user, group kaj chroot. Dosiero sub hejmdosierujo povas esti legebla en via ŝelo kaj nevidebla ene de la servo, post kiam hejmdosierujoj kaŝiĝas. La konto, per kiu systemd startas, ne ĉiam estas la konto, kiu finfine malfermas la ŝlosilon.

Pruvu, ke la rultempa identeco povas malfermi ambaŭ dosierojn

Legi la modon ne sufiĉas, ĉar ĉiu dosierujo sur la vojo devas esti trapasebla de la sama identeco. Trapasu la vojon komponenton post komponento, poste testu la malfermon kiel la konto, kiun la procezo uzas. Dosiero kun modo 600 posedata de root funkcias nur dum la procezo ankoraŭ estas root, kio ne veras post la privilegia malaltigo, kiun multaj profiloj faras. Du komandoj kovras la traparadon kaj la malfermon:

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

La unua komando presas la modon de ĉiu komponento kaj malsukcesas tie, kie la konto ne povas trapasi; la dua respondas la solan gravan demandon, ĉu la rultempa identeco povas malfermi la dosieron por legado. Neniu presas dosieran enhavon, kaj tio estas la celo, kiam la dosiero tenas pasfrazon. Ripetu la teston por la ensaluta dosiero, ĉar la du ofte konserviĝas kun malsama posedo.

Se la procezo uzas chroot aŭ limigitan namespace, rulu la saman teston de interne de tiu vido, alie la respondo priskribas la malĝustan dosiersistemon. Pasfrazo konservita sub kaŝita hejmdosierujo estas la kutima ekzemplo de testo, kiu pasas ekster la unuo kaj malsukcesas ene de ĝi.

Kontrolu la unuan starton, poste rekonekton

Startu la instancon unufoje kaj legu la unuan malsukceson, ne la lastan. Mankanta eniga dosiero, malsukcesinta ŝlosila malĉifrado kaj AUTH_FAILED de la servilo estas tri malsamaj eventoj kun tri malsamaj riparoj. Ripari permesan averton pruvas nenion pri tio, ĉu la ŝlosilo malŝlosiĝis.

La ĵurnala linio diras, kiun el la tri vi havas. La riparo sekvas el tio, kiu enigo malsukcesis:

Poste testu la vivociklon, kiun vi efektive bezonas: starton ĉe la lanĉo kaj ĉiun subtenatan rekonekton, ne nur manan starton el via ŝelo. Kun auth-nocache la enigoj forĵetiĝas post la unua uzo, do pli posta rekonekto ankoraŭ bezonas legeblan fonton. Ŝlosilaro malŝlosita ĉe labortabla ensaluto ne disponeblas al servo, kiu startis antaŭ ol iu ajn ensalutis, kaj tio estas la kutima kialo, ke mana testo pasas kaj restarto malsukcesas. Se la unua starto sukcesas kaj pli posta rekonekto malsukcesas, legu la ĵurnalon pri la rekonekta evento antaŭ ol denove ŝanĝi permesojn.

Konservi la pasfrazon apud la ŝlosilo malpliigas tion, kion la ĉifrado donas al vi, do limigu tiun dosieron kaj ĝiajn sekurkopiojn. Traktu forigon de la ŝlosila pasfrazo kiel apartan legitimilan decidon, ne kiel riparon por mankanta enigo. Deplojo, kiu dependas de homa aprobo aŭ interaga MFA, bezonas sian subtenatan agenton aŭ administran integriĝon; permanente konservita unufoja kodo ne estas ekvivalenta anstataŭaĵo.