Den OpenVPN-Service bleift beim Ufro vum Passwuert vum private Schlëssel stoen: sou behieft een dat
E Service huet keen Terminal, also brauch en verschlësselte Schlëssel askpass an eng liesbar Datei. Trennt d’Passphrase vum Schlëssel vum Server-Login a kontrolléiert d’Unit.
OpenVPN freet d’Passphrase vum private Schlëssel op der lokaler Maschinn, also äntwert eng funktionéierend Login-Datei ni dorop. An engem Service gëtt et keen Terminal fir ze tippen, an de Start entweder hänkt oder schléit fehl mat engem Journal-Antrag, deen den Input an net d’Ursaach nennt. Et sinn zwou Geheimnisser am Spill, an alleng brauch seng eegen liesbar Quell, ier d’Unit nei gestart gëtt. De Wee hei ënnen trennt se, an da kontrolléiert en d’Identitéit, déi tatsächlech all Datei opmécht.
Trennt déi zwou Ufroen
D’Passphrase vum Schlëssel entschlësselt de lokale private Schlëssel; d’Kontdonnéeë authentifizéieren d’Sessioun beim Server. Si komme vun ënnerschiddleche Plazen, schléie zu ënnerschiddleche Momenter fehl an erginn ënnerschiddlech Messagen. Si verwiesselen schéckt d’Leit eng Passwuert-Reset sichen, obwuel de Kont guer net bedeelegt war. Liest den Text vun der Ufro, ier Dir eng Optioun ännert, well d’Formuléierung deen eenzegen zouverlässegen Hiweis ass, wéi eng Geheimnis feelt.
A Community OpenVPN 2.x nennt askpass eng Datei, déi d’Passphrase vum Schlëssel an der éischter Zeil hält, an auth-user-pass eng Datei mat dem Benotzernumm an enger Zeil an dem Passwuert an der nächster. Keng vun den zwou Dateien erfëllt déi aner Optioun. Eng Desktop-App oder e NetworkManager-Profil kann béides a sengem eegene Geheimnisspeicher halen, deen e Kommandozeile-Client ni liest, also notéiert wéi ee Client Dir konfiguréiert, ier Dir ee Wee schreift.
Richt béid Optiounen op liesbar Dateien
E Profil, deen béid Inputs brauch, hält am Schluss dräi Dateireferenzen: de verschlësselte Schlëssel, d’Passphrase déi en opmécht an d’Login-Puer. Füügt se derbäi, ouni d’CA oder d’Identitéitskontrollen unzeréieren, well déi entscheeden, wien de Server ass, an net Deel vun dësem Problem sinn. Wann d’Deployment guer keng Kontdonnéeë benotzt, schaaft auth-user-pass en Input, deen een net ka liwweren.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authOptiounen ouni Argument verhale sech anescht wéi Optiounen mat Wee, an an engem Service ass den Ënnerscheed wichteg. En askpass ouni Argument liest nach ëmmer d’Konsole, an eng auth-user-pass-Datei mat nëmmen engem Benotzernumm léisst nach ëmmer eng Passwuert-Ufro waarden. Soubal de Client daemoniséiert, kann en en Terminal guer net méi ëm Input freen, also kënnt en esou konfiguréierte Service net erop.
Absolut Weeër huelen d’Fro nom Aarbechtsverzeechnis ewech, ginn awer keen Zougang. Besëtz, Modus an Duerchgang kommen duerno, an all dräi ginn am Verglach mat dem Kont gepréift, ënner deem de Prozess leeft.
Liest d’Konfiguratioun vun der Unit virum Profil
D’Unit, net d’Datei déi Dir editéiert hutt, entscheet wéi eng Konfiguratioun d’Instanz lued. Liest seng Kommandozeile an all Drop-ins, an da follegt dem Aarbechtsverzeechnis bis zum Profil, deen tatsächlech benotzt gëtt. Eng Passphrase-Referenz, déi an eng aner .ovpn-Datei gesat gëtt, ännert fir dës Instanz näischt.
Dräi nëmme-Lies-Befehler beäntweren de gréissten Deel. Den éischten dréckt d’Unit an all Drop-ins, den zweeten d’Identitéit an d’Sandbox-Astellunge, déi de Prozess bannen, an den drëtten, wat de leschte Start tatsächlech bekloen huet. Benotzt den Instanznumm, deen um Host existéiert:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bPasst op ProtectHome an op d’eegen Optioune vum Profil user, group an chroot op. Eng Datei ënner engem Heemverzeechnis ka an Ärer Shell liesbar an am Service onsichtbar sinn, wann Heemverzeechnisser verstoppt ginn. De Kont, mat deem systemd start, ass net ëmmer dee Kont, deen am Schluss de Schlëssel opmécht.
Beweist, datt d’Runtime-Identitéit béid Dateie kann opmaachen
De Modus ze liesen ass net genuch, well all Verzeechnis um Wee vun der selwechter Identitéit duerchgaang ka ginn. Gitt de Wee Komponent fir Komponent duerch, an testt dann d’Opmaachen als dee Kont, deen de Prozess benotzt. Eng Datei mam Modus 600 am Besëtz vu root funktionéiert nëmme soulaang de Prozess nach root ass, wat no der Privilegie-Senkung, déi vill Profiler maachen, net méi stëmmt. Zwee Befehler decken den Duerchgang an d’Opmaachen of:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableDen éischte Befehl dréckt de Modus vun all Komponent an a schléit do fehl, wou de Kont net duerchkënnt; den zweeten äntwert op déi eenzeg wichteg Fro, ob d’Runtime-Identitéit d’Datei kann zum Liesen opmaachen. Kee vun deenen zwee dréckt den Inhalt vun der Datei, an dat ass just de Punkt, wann d’Datei eng Passphrase hält. Widderholl den Test fir d’Login-Datei, well déi zwou dacks mat ënnerschiddlechem Besëtz gespäichert ginn.
Wann de Prozess e chroot oder en agegrenzten namespace benotzt, fuert deen selwechten Test vun bannen aus dëser Vue, soss beschreift d’Äntwert de falsche Dateisystem. Eng Passphrase, déi ënner engem verstoppten Heemverzeechnis gespäichert ass, ass dat üblech Beispill vun engem Test, deen ausserhalb vun der Unit duerchgeet an bannen dra feelt.
Kontrolléiert den éischte Start, dann eng Widderverbindung
Start d’Instanz eemol a liest den éischte Fehler an net de leschten. Eng feelend Input-Datei, eng feelgeschloe Schlëssel-Entschlësselung an en AUTH_FAILED vum Server sinn dräi verschidde Evenementer mat dräi verschiddene Reparaturen. Eng Berechtegungs-Warnung ze behiewen beweist näischt doriwwer, ob de Schlëssel opgemaach gouf.
D’Journal-Zeil seet, wéi ene vun den dräi Dir hutt. D’Reparatur follegt doraus, wéi en Input feelgeschloen ass:
| 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 |
Da testt de Liewenszyklus, deen Dir tatsächlech braucht: e Start beim Booten an all ënnerstëtzt Widderverbindung, net just en manuelle Start aus Ärer Shell. Mat auth-nocache ginn d’Inputs no der éischter Benotzung verkaaft, also brauch eng spéider Widderverbindung nach ëmmer eng liesbar Quell. En Schlësselrank, deen beim Desktop-Login opgemaach gëtt, ass fir e Service net verfügbar, deen ugefaangen huet, ier een sech ageloggt huet, an dat ass de üblech Grond, firwat en manuellen Test duerchgeet an e Neistart feelt. Wann den éischte Start geléngt an eng spéider Widderverbindung feelt, liest de Journal fir d’Widderverbindungs-Evenement, ier Dir d’Berechtegungen nach eng Kéier ännert.
D’Passphrase niewent dem Schlëssel ze späicheren reduzéiert, wat d’Verschlësselung Iech gëtt, also limitéiert déi Datei an hir Backups. Betruecht d’Ewechhuele vun der Schlëssel-Passphrase als eng separat Entscheedung zu den Umeldungsdaten an net als Reparatur fir en feelenden Input. En Deployment, dee vun mënschlecher Genehmegung oder interaktiver MFA ofhänkt, brauch säin ënnerstëtzten Agent oder seng Verwaltungsintegratioun; en dauerhaft gespäicherte Eenmol-Code ass keen equivalent Ersatz.