OpenVPN-dienst blijft hangen bij de vraag om het wachtwoord van de privésleutel: zo los je het op

OpenVPN vraagt de wachtwoordzin van de privésleutel op de lokale machine, dus een werkend loginbestand beantwoordt die nooit. Bij een dienst is er geen terminal om in te typen, en de start blijft hangen of mislukt met een journaalregel die de invoer noemt in plaats van de oorzaak. Er zijn twee geheimen in het spel, en elk heeft zijn eigen leesbare bron nodig voordat de unit opnieuw wordt gestart. De onderstaande gang scheidt ze en controleert daarna de identiteit die elk bestand werkelijk opent.

Onderscheid de twee vragen

De wachtwoordzin van de sleutel ontsleutelt de lokale privésleutel; de accountgegevens authenticeren de sessie bij de server. Ze komen van verschillende plekken, falen op verschillende momenten en geven verschillende meldingen. Ze verwarren stuurt mensen op zoek naar een wachtwoordreset terwijl het account er niets mee te maken had. Lees de tekst van de vraag voordat je een optie wijzigt, want de formulering is de enige betrouwbare aanwijzing welk geheim ontbreekt.

In Community OpenVPN 2.x wijst askpass een bestand aan dat de wachtwoordzin van de sleutel op de eerste regel heeft, en auth-user-pass een bestand met de gebruikersnaam op één regel en het wachtwoord op de volgende. Geen van beide bestanden kan de andere optie vervullen. Een desktop-app of een NetworkManager-profiel kan beide in zijn eigen geheimenopslag bewaren, die een opdrachtregelclient nooit leest, dus noteer welke client je configureert voordat je een pad schrijft.

Wijs beide opties naar leesbare bestanden

Een profiel dat beide invoeren nodig heeft, eindigt met drie bestandsverwijzingen: de versleutelde sleutel, de wachtwoordzin die hem ontgrendelt en het loginpaar. Voeg ze toe zonder de CA of de identiteitscontroles aan te raken, want die bepalen wie de server is en horen niet bij dit probleem. Als de uitrol helemaal geen accountgegevens gebruikt, maakt auth-user-pass een invoer die niemand kan leveren.

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

Opties zonder argument gedragen zich anders dan opties met een pad, en in een dienst is dat verschil belangrijk. Een askpass zonder argument leest nog steeds de console, en een auth-user-pass-bestand met alleen een gebruikersnaam laat nog steeds een wachtwoordvraag wachten. Zodra de client daemoniseert, kan hij een terminal helemaal niet om invoer vragen, dus een zo geconfigureerde dienst komt niet op.

Absolute paden nemen de vraag naar de werkmap weg, maar geven geen toegang. Eigendom, modus en doorgang komen daarna, en alle drie worden getoetst aan het account waaronder het proces draait.

Lees de configuratie van de unit vóór het profiel

De unit, niet het bestand dat je bewerkte, bepaalt welke configuratie de instantie laadt. Lees de opdrachtregel en eventuele drop-ins en volg dan de werkmap naar het profiel dat werkelijk wordt gebruikt. Een wachtwoordzinverwijzing in een ander .ovpn-bestand verandert niets voor deze instantie.

Drie alleen-lezen-opdrachten beantwoorden het meeste. De eerste toont de unit en eventuele drop-ins, de tweede de identiteit en de sandbox-instellingen die het proces binden, en de derde waarover de laatste start werkelijk klaagde. Gebruik de instantienaam die op de host bestaat:

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 de eigen opties van het profiel user, group en chroot. Een bestand onder een thuismap kan in je shell leesbaar zijn en binnen de dienst onzichtbaar zodra thuismappen worden verborgen. Het account waarmee systemd start is niet altijd het account dat uiteindelijk de sleutel opent.

Bewijs dat de runtime-identiteit beide bestanden kan openen

De modus lezen is niet genoeg, want elke map op het pad moet door dezelfde identiteit te passeren zijn. Loop het pad component voor component door en test dan het openen als het account dat het proces gebruikt. Een bestand met modus 600 in bezit van root werkt alleen zolang het proces nog root is, wat niet geldt na de rechtendaling die veel profielen uitvoeren. Twee opdrachten dekken de doorgang en het openen:

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

De eerste opdracht toont de modus van elke component en faalt waar het account niet kan passeren; de tweede beantwoordt de enige belangrijke vraag, namelijk of de runtime-identiteit het bestand kan openen om te lezen. Geen van beide toont de inhoud van het bestand, en dat is precies het punt wanneer het bestand een wachtwoordzin bevat. Herhaal de test voor het loginbestand, want de twee worden vaak met verschillend eigenaarschap opgeslagen.

Als het proces een chroot of een beperkte namespace gebruikt, voer dezelfde test dan van binnenuit die weergave uit, anders beschrijft het antwoord het verkeerde bestandssysteem. Een wachtwoordzin onder een verborgen thuismap is het gebruikelijke voorbeeld van een test die buiten de unit slaagt en erbinnen faalt.

Controleer de eerste start en daarna een herverbinding

Start de instantie één keer en lees de eerste fout in plaats van de laatste. Een ontbrekend invoerbestand, een mislukte sleutelontsleuteling en een AUTH_FAILED van de server zijn drie verschillende gebeurtenissen met drie verschillende reparaties. Een permissiewaarschuwing oplossen bewijst niets over de vraag of de sleutel is ontgrendeld.

De journaalregel zegt welke van de drie je hebt. De reparatie volgt uit welke invoer faalde:

Test daarna de levenscyclus die je echt nodig hebt: een start bij het booten en elke ondersteunde herverbinding, niet alleen een handmatige start vanuit je shell. Met auth-nocache worden de invoeren na het eerste gebruik weggegooid, dus een latere herverbinding heeft nog steeds een leesbare bron nodig. Een sleutelring die bij de desktoplogin wordt ontgrendeld, is niet beschikbaar voor een dienst die startte voordat iemand inlogde, en dat is de gebruikelijke reden waarom een handmatige test slaagt en een herstart mislukt. Als de eerste start lukt en een latere herverbinding mislukt, lees dan het journaal voor de herverbindingsgebeurtenis voordat je opnieuw permissies wijzigt.

De wachtwoordzin naast de sleutel bewaren vermindert wat de versleuteling je oplevert, dus beperk dat bestand en zijn back-ups. Behandel het verwijderen van de wachtwoordzin van de sleutel als een aparte beslissing over inloggegevens, niet als de reparatie voor een ontbrekende invoer. Een uitrol die afhangt van menselijke goedkeuring of interactieve MFA heeft zijn ondersteunde agent of beheerintegratie nodig; een permanent opgeslagen eenmalige code is geen gelijkwaardige vervanging.