OpenVPN-diens hang by die private-sleutelwagwoord: so herstel jy dit

OpenVPN vra die private-sleutelwagwoord op die plaaslike masjien, so ’n werkende aanmeldlêer antwoord dit nooit. Op ’n diens is daar geen terminal om in te tik nie, en die begin hang óf misluk met ’n joernaalinskrywing wat die invoer noem eerder as die oorsaak. Twee geheime is betrokke, en elkeen het sy eie leesbare bron nodig voordat die unit herbegin word. Die stappe hieronder skei hulle, en kontroleer dan die identiteit wat elke lêer werklik oopmaak.

Onderskei die twee vrae

Die sleutelwagwoord ontsluit die plaaslike private sleutel; die rekeninggeloofsbriewe verifieer die sessie by die bediener. Hulle kom van verskillende plekke, misluk op verskillende oomblikke en lewer verskillende boodskappe. Om hulle te verwar, laat mense na ’n wagwoordherstel soek terwyl die rekening nooit betrokke was nie. Lees die vraagteks voordat jy enige opsie verander, want die bewoording is die enigste betroubare leidraad oor watter geheim ontbreek.

In Community OpenVPN 2.x wys askpass na ’n lêer wat die sleutelwagwoord op sy eerste reël hou, en auth-user-pass wys na ’n lêer met die gebruikersnaam op een reël en die wagwoord op die volgende. Nie een van die twee lêers kan die ander opsie bevredig nie. ’n Lessenaartoepassing of ’n NetworkManager-profiel kan albei in sy eie geheimeberging hou, wat ’n opdragreël-kliënt nooit lees nie, so let op watter kliënt jy opstel voordat jy enige pad skryf.

Wys beide opsies na leesbare lêers

’n Profiel wat albei insette nodig het, eindig met drie lêerverwysings: die geïnkripteerde sleutel, die wagwoord wat dit ontsluit, en die aanmeldpaar. Voeg hulle by sonder om die CA of die identiteitskontroles te raak, want dié bepaal wie die bediener is en is nie deel van hierdie probleem nie. As die ontplooiing glad nie rekeninggeloofsbriewe gebruik nie, skep auth-user-pass ’n invoer wat niemand kan verskaf nie.

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

Kaal opsies gedra hulle anders as opsies met paaie, en die verskil maak saak op ’n diens. ’n askpass sonder ’n argument lees steeds die konsole, en ’n auth-user-pass-lêer met net ’n gebruikersnaam laat steeds ’n wagwoordvraag wag. Sodra die kliënt daemoniseer, kan dit glad nie ’n terminal om invoer vra nie, so ’n diens wat so opgestel is, kom nie op nie.

Absolute paaie verwyder die vraag oor die werkende gids, maar verleen nie toegang nie. Eienaarskap, modus en deurgang kom volgende, en al drie word teen die rekening waaronder die proses loop, getoets.

Lees die unit se konfigurasie voor die profiel

Die unit, nie die lêer wat jy geredigeer het nie, besluit watter konfigurasie die instansie laai. Lees sy opdragreël en enige drop-ins, en volg dan die werkende gids na die profiel wat werklik in gebruik is. ’n Wagwoordverwysing wat by ’n ander .ovpn-lêer gevoeg word, verander niks vir hierdie instansie nie.

Drie lees-alleen-opdragte antwoord die meeste daarvan. Die eerste druk die unit en enige drop-ins, die tweede druk die identiteit en sandboksmettings wat die proses bind, en die derde druk waaroor die laaste begin werklik gekla het. Gebruik die instansienaam wat op die gasheer bestaan:

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

Let op ProtectHome en op die profiel se eie user-, group- en chroot-opsies. ’n Lêer onder ’n tuisgids kan in jou skulp leesbaar wees en binne die diens onsigbaar sodra tuisgidse versteek word. Die rekening waarmee systemd begin, is nie altyd die rekening wat die sleutel uiteindelik oopmaak nie.

Bewys dat die runtime-identiteit albei lêers kan oopmaak

Om die modus te lees is nie genoeg nie, want elke gids op die pad moet deur dieselfde identiteit deurgangbaar wees. Stap die pad komponent vir komponent, en toets dan die oopmaak as die rekening wat die proses gebruik. ’n Lêer met modus 600 wat aan root behoort, werk net terwyl die proses nog root is, wat nie waar is ná die voorregverlaging wat baie profiele doen nie. Twee opdragte dek die deurgang en die oopmaak:

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

Die eerste opdrag druk die modus van elke komponent en misluk waar die rekening nie kan deurgang nie; die tweede antwoord die enigste vraag wat saak maak, naamlik of die runtime-identiteit die lêer vir lees kan oopmaak. Nie een druk lêerinhoud nie, en dit is die punt wanneer die lêer ’n wagwoord hou. Herhaal die toets vir die aanmeldlêer, want die twee word dikwels met verskillende eienaarskap gestoor.

As die proses ’n chroot of ’n beperkte naamruimte gebruik, loop dieselfde toets van binne daardie siening, anders beskryf die antwoord die verkeerde lêerstelsel. ’n Wagwoord wat onder ’n versteekte tuisgids gestoor is, is die gewone voorbeeld van ’n toets wat buite die unit slaag en binne-in misluk.

Kontroleer die eerste begin, dan ’n herverbinding

Begin die instansie een keer en lees die eerste mislukking eerder as die laaste. ’n Ontbrekende invoerlêer, ’n mislukte sleutelontsleuteling en ’n bedienerkant-AUTH_FAILED is drie verskillende gebeure met drie verskillende herstellings. Om ’n toestemmingswaarskuwing reg te maak, bewys niks oor of die sleutel ontsluit is nie.

Die joernaalreël sê watter van die drie jy het. Die herstelling volg uit watter invoer misluk het:

Toets dan die lewensiklus wat jy werklik nodig het: ’n selflaai-begin en enige ondersteunde herverbinding, nie net ’n handmatige begin uit jou skulp nie. Met auth-nocache word die insette ná die eerste gebruik laat vaar, so ’n latere herverbinding het steeds ’n leesbare bron nodig. ’n Sleutelring wat by lessenaar-aanmelding ontsluit word, is nie beskikbaar vir ’n diens wat begin het voordat iemand aangemeld het nie, en dit is die gewone rede waarom ’n handmatige toets slaag en ’n herlaai misluk. As die eerste begin slaag en ’n latere herverbinding misluk, lees die joernaal vir die herverbinding-gebeurtenis voordat jy weer toestemmings verander.

Om die wagwoord langs die sleutel te stoor, verminder wat die enkripsie vir jou koop, so beperk daardie lêer en sy rugsteune. Behandel die verwydering van die sleutelwagwoord as ’n aparte geloofsbriefbeslissing eerder as die herstelling vir ’n ontbrekende invoer. ’n Ontplooiing wat van menslike goedkeuring of interaktiewe MFA afhang, het sy ondersteunde agent of bestuursintegrasie nodig; ’n permanent gestoorde eenmalige kode is nie ’n gelykwaardige vervanging nie.