OpenVPN pakalpojums apstājas, pieprasot privātās atslēgas paroli: kā to salabot
Pakalpojumam nav termināļa, tāpēc šifrētai atslēgai vajag askpass un lasāmu failu. Atdaliet atslēgas paroli no pieteikšanās serverī un pārbaudiet unit.
OpenVPN prasa privātās atslēgas paroli vietējā mašīnā, tāpēc strādājošs pieteikšanās fails uz to nekad neatbild. Pakalpojumā nav termināļa rakstīšanai, un palaišana vai nu iekaras, vai neizdodas ar žurnāla ierakstu, kas nosauc ievadi, nevis cēloni. Šeit ir divi noslēpumi, un katram pirms unit pārstartēšanas vajag savu lasāmu avotu. Tālāk aprakstītā gaita tos atdala un pēc tam pārbauda identitāti, kas patiešām atver katru failu.
Atšķiriet abus pieprasījumus
Atslēgas parole atšifrē vietējo privāto atslēgu; konta dati autentificē sesiju serverī. Tie nāk no dažādām vietām, neizdodas dažādos brīžos un sniedz dažādus ziņojumus. To sajaukšana sūta cilvēkus meklēt paroles atiestatīšanu, lai gan konts nemaz nebija iesaistīts. Pirms mainīt jebkuru opciju, izlasiet pieprasījuma tekstu, jo formulējums ir vienīgā uzticamā norāde, kura noslēpuma trūkst.
Community OpenVPN 2.x askpass nosauc failu, kura pirmajā rindā ir atslēgas parole, un auth-user-pass nosauc failu, kurā vienā rindā ir lietotājvārds un nākamajā – parole. Neviens no failiem neapmierina otru opciju. Darbvirsmas lietotne vai NetworkManager profils var turēt abus savā noslēpumu krātuvē, ko komandrindas klients nekad nelasa, tāpēc pirms jebkura ceļa rakstīšanas atzīmējiet, kuru klientu konfigurējat.
Norādiet abas opcijas uz lasāmiem failiem
Profils, kuram vajag abas ievades, galu galā iegūst trīs failu atsauces: šifrēto atslēgu, to atverošo paroli un pieteikšanās pāri. Pievienojiet tās, neaiztiekot CA un identitātes pārbaudes, jo tās nosaka, kas ir serveris, un nav šīs problēmas daļa. Ja izvietojums vispār neizmanto konta datus, pievienojot auth-user-pass, rodas ievade, ko neviens nevar sniegt.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authOpcijas bez argumenta uzvedas citādi nekā opcijas ar ceļu, un pakalpojumā šī atšķirība ir svarīga. askpass bez argumenta joprojām lasa konsoli, un auth-user-pass fails ar tikai lietotājvārdu joprojām atstāj gaidām paroles pieprasījumu. Kad klients kļūst par dēmonu, tas vispār nevar pieprasīt ievadi no termināļa, tāpēc šādi konfigurēts pakalpojums neceļas.
Absolūtie ceļi novērš darba direktorijas jautājumu, bet nedod piekļuvi. Tālāk nāk īpašnieks, režīms un caureja, un visi trīs tiek pārbaudīti pret kontu, ar kuru darbojas process.
Vispirms izlasiet unit konfigurāciju, tad profilu
Kuru konfigurāciju ielādē eksemplārs, izlemj unit, nevis fails, ko rediģējāt. Izlasiet tā komandrindu un visus drop-in, pēc tam sekojiet darba direktorijai līdz profilam, kas patiešām tiek lietots. Paroles atsauce, kas pievienota citam .ovpn failam, šim eksemplāram neko nemaina.
Trīs tikai lasīšanas komandas atbild uz lielāko daļu. Pirmā izdrukā unit un visus drop-in, otrā – identitāti un procesu ierobežojošos sandbox iestatījumus, trešā – par ko pēdējā palaišana patiešām sūdzējās. Izmantojiet eksemplāra nosaukumu, kas eksistē resursdatorā:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bPievērsiet uzmanību ProtectHome un paša profila opcijām user, group un chroot. Fails mājas direktorijā var būt lasāms jūsu čaulā un neredzams pakalpojuma iekšienē, kad mājas direktorijas tiek paslēptas. Konts, ar kuru startē systemd, ne vienmēr ir tas konts, kas galu galā atver atslēgu.
Pierādiet, ka izpildes identitāte var atvērt abus failus
Nepietiek nolasīt režīmu, jo katrai ceļa direktorijai jābūt caurejamai tai pašai identitātei. Izejiet ceļu pa komponentiem un pēc tam pārbaudiet atvēršanu kā konts, ko izmanto process. Fails ar režīmu 600, kas pieder root, darbojas tikai tikmēr, kamēr process vēl ir root, kas pēc daudzu profilu veiktās privilēģiju samazināšanas vairs nav taisnība. Divas komandas aptver caureju un atvēršanu:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readablePirmā komanda izdrukā katra komponenta režīmu un neizdodas tur, kur konts nevar iziet; otrā atbild uz vienīgo svarīgo jautājumu – vai izpildes identitāte var atvērt failu lasīšanai. Neviena neizdrukā faila saturu, un tas ir būtiskais, kad failā ir parole. Atkārtojiet pārbaudi pieteikšanās failam, jo abi bieži tiek glabāti ar atšķirīgu īpašnieku.
Ja process izmanto chroot vai ierobežotu namespace, palaidiet to pašu pārbaudi no šī skata iekšpuses, citādi atbilde apraksta nepareizu failu sistēmu. Parole, kas glabāta zem paslēptas mājas direktorijas, ir ierastais piemērs pārbaudei, kas iztur ārpus unit un neizdodas tā iekšienē.
Pārbaudiet pirmo palaišanu, tad atkārtotu savienojumu
Palaidiet eksemplāru vienu reizi un lasiet pirmo, nevis pēdējo kļūdu. Trūkstošs ievades fails, neizdevusies atslēgas atšifrēšana un no servera puses saņemts AUTH_FAILED ir trīs dažādi notikumi ar trim dažādiem labojumiem. Atļauju brīdinājuma izlabošana neko nepierāda par to, vai atslēga tika atvērta.
Žurnāla rinda pasaka, kurš no trim. Labojums izriet no tā, kura ievade neizdevās:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Pēc tam pārbaudiet dzīves ciklu, kas jums patiešām vajadzīgs: palaišanu sāknēšanas laikā un jebkuru atbalstītu atkārtotu savienojumu, ne tikai manuālu palaišanu no jūsu čaulas. Ar auth-nocache ievades tiek izmestas pēc pirmās lietošanas, tāpēc vēlākam atkārtotam savienojumam joprojām vajag lasāmu avotu. Atslēgu pūrs, kas tiek atvērts darbvirsmas pieteikšanās laikā, nav pieejams pakalpojumam, kas startēja pirms kāds pieteicās, un tas ir ierastais iemesls, kāpēc manuāla pārbaude iztur, bet pārstartēšana neizdodas. Ja pirmā palaišana izdodas un vēlāks atkārtots savienojums neizdodas, izlasiet žurnālu par atkārtotā savienojuma notikumu, pirms atkal mainīt atļaujas.
Paroles glabāšana blakus atslēgai samazina to, ko dod šifrēšana, tāpēc ierobežojiet šo failu un tā dublējumus. Atslēgas paroles noņemšanu uzskatiet par atsevišķu pieteikšanās datu lēmumu, nevis trūkstošas ievades labojumu. Izvietojumam, kas atkarīgs no cilvēka apstiprinājuma vai interaktīvas MFA, vajag atbalstītu aģentu vai pārvaldības integrāciju; pastāvīgi saglabāts vienreizējs kods nav līdzvērtīgs aizstājējs.