OpenVPN servis staje na unosu lozinke privatnog ključa: kako to popraviti

OpenVPN traži frazu privatnog ključa na lokalnom računaru, pa radna datoteka za prijavu nikada na nju ne odgovara. U servisu nema terminala za unos, a pokretanje ili visi, ili pada uz zapis u dnevniku koji imenuje unos, a ne uzrok. U igri su dvije tajne i svaka prije ponovnog pokretanja unita treba vlastiti čitljivi izvor. Postupak ispod ih razdvaja, a zatim provjerava identitet koji stvarno otvara svaku datoteku.

Razlikujte dva upita

Fraza ključa dešifruje lokalni privatni ključ; podaci računa provjeravaju sesiju prema serveru. Dolaze s različitih mjesta, padaju u različitim trenucima i daju različite poruke. Brkanje ih šalje ljude u potragu za resetom lozinke, iako račun nikada nije bio uključen. Pročitajte tekst upita prije mijenjanja bilo koje opcije, jer je formulacija jedini pouzdan trag koja tajna nedostaje.

U Community OpenVPN 2.x askpass označava datoteku koja drži frazu ključa u prvom redu, a auth-user-pass datoteku s korisničkim imenom u jednom redu i lozinkom u sljedećem. Nijedna datoteka ne može zadovoljiti drugu opciju. Desktop aplikacija ili profil NetworkManagera mogu oboje držati u vlastitoj pohrani tajni, koju klijent iz komandne linije nikada ne čita, pa zabilježite koji klijent konfigurišete prije nego napišete bilo koju putanju.

Usmjerite obje opcije na čitljive datoteke

Profil koji treba oba unosa na kraju ima tri reference na datoteke: šifrirani ključ, frazu koja ga otključava i par za prijavu. Dodajte ih ne dirajući CA ni provjere identiteta, jer one odlučuju ko je server i nisu dio ovog problema. Ako implementacija uopće ne koristi podatke računa, auth-user-pass stvara unos koji niko ne može dostaviti.

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

Gole opcije ponašaju se drugačije od opcija s putanjama, a razlika je važna na servisu. askpass bez argumenta još čita konzolu, a datoteka auth-user-pass samo s korisničkim imenom još ostavlja upit za lozinku na čekanju. Kad klijent pređe u demon, uopće ne može tražiti unos s terminala, pa se servis tako konfigurisan ne podiže.

Apsolutne putanje uklanjaju pitanje radnog direktorija, ali ne daju pristup. Vlasništvo, mod i prolaženje slijede, a sve troje se provjerava prema računu pod kojim proces radi.

Pročitajte konfiguraciju unita prije profila

Koju konfiguraciju instanca učitava odlučuje unit, a ne datoteka koju ste uređivali. Pročitajte njegovu komandnu liniju i sve drop-in datoteke, pa slijedite radni direktorij do profila koji se stvarno koristi. Referenca fraze dodana u drugu .ovpn datoteku ne mijenja ništa za ovu instancu.

Tri komande samo za čitanje odgovaraju na većinu toga. Prva ispisuje unit i sve drop-in datoteke, druga ispisuje identitet i sandbox postavke koje ograničavaju proces, a treća ispisuje na šta se posljednje pokretanje stvarno požalilo. Koristite naziv instance koji postoji na hostu:

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

Obratite pažnju na ProtectHome i na vlastite opcije profila user, group i chroot. Datoteka u kućnom direktoriju može biti čitljiva u vašem shellu, a nevidljiva unutar servisa kad se kućni direktoriji sakriju. Račun s kojim systemd starta nije uvijek račun koji na kraju otvara ključ.

Dokažite da identitet izvršavanja može otvoriti obje datoteke

Čitanje moda nije dovoljno, jer svaki direktorij na putanji mora biti prohodan za isti identitet. Prođite putanju komponentu po komponentu, pa isprobajte otvaranje kao račun koji proces koristi. Datoteka s modom 600 u vlasništvu roota radi samo dok je proces još root, što ne vrijedi nakon snižavanja privilegija koje mnogi profili rade. Dvije komande pokrivaju prolaženje i otvaranje:

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

Prva komanda ispisuje mod svake komponente i pada gdje račun ne može proći; druga odgovara na jedino važno pitanje — može li identitet izvršavanja otvoriti datoteku za čitanje. Nijedna ne ispisuje sadržaj datoteke i to je poenta kad datoteka drži frazu. Ponovite test za datoteku prijave, jer se dvije često čuvaju s različitim vlasništvom.

Ako proces koristi chroot ili ograničeni namespace, pokrenite isti test iznutra tog prikaza, inače odgovor opisuje pogrešan sistem datoteka. Fraza pohranjena pod skrivenim kućnim direktorijem uobičajen je primjer testa koji prolazi izvan unita i pada unutar njega.

Provjerite prvo pokretanje, pa ponovno spajanje

Pokrenite instancu jednom i pročitajte prvi, a ne posljednji pad. Datoteka unosa koja nedostaje, neuspjelo dešifriranje ključa i AUTH_FAILED sa servera tri su različita događaja s tri različita popravka. Popravljanje upozorenja o dozvolama ne dokazuje ništa o tome je li ključ otključan.

Red u dnevniku kaže koji od tri imate. Popravak slijedi iz toga koji je unos pao:

Zatim testirajte životni ciklus koji vam stvarno treba: pokretanje pri dizanju i svako podržano ponovno spajanje, ne samo ručno pokretanje iz vašeg shella. Uz auth-nocache unosi se odbacuju nakon prve upotrebe, pa kasnije ponovno spajanje još treba čitljiv izvor. Prsten ključeva otključan pri prijavi na desktop nije dostupan servisu koji je startao prije nego se bilo ko prijavio, i to je uobičajen razlog zašto ručni test prolazi, a restart pada. Ako prvo pokretanje uspije, a kasnije ponovno spajanje padne, pročitajte dnevnik za događaj ponovnog spajanja prije nego ponovo mijenjate dozvole.

Čuvanje fraze uz ključ smanjuje ono što šifriranje daje, pa ograničite tu datoteku i njene sigurnosne kopije. Uklanjanje fraze ključa tretirajte kao odvojenu odluku o akreditivima, a ne kao popravak unosa koji nedostaje. Implementacija koja zavisi od ljudskog odobrenja ili interaktivne MFA treba podržanog agenta ili integraciju za upravljanje; trajno sačuvan jednokratni kod nije ekvivalentna zamjena.