Het VPN-wachtwoord moet ergens leven: in het verbindingsprofiel, in een sleutelring die de desktop ontgrendelt, of nergens. NetworkManager noemt die keuze een geheime vlag, en de verkeerde kiezen is de reden dat een verbinding na inloggen werkt en als dienst faalt. De vlag is één regel configuratie, en hij bepaalt welk van die drie uitkomsten je krijgt.

Drie vlaggen dekken bijna elk geval, en de beslissing gaat over wanneer de verbinding start.

Drie geheime vlaggen, drie gedragingen

Een vlag van 0 betekent dat het geheim met de verbinding wordt opgeslagen, in welke opslag het profiel ook staat. Een vlag van 1 maakt het agent-eigendom: het geheim komt van een geheimagent zoals een desktopsleutelring, en NetworkManager vraagt erom bij activering. Een vlag van 2 betekent niet opgeslagen, dus het geheim wordt nooit geschreven en moet elke keer worden geleverd. Vlag 4 markeert een geheim als niet vereist, voor verbindingen die er werkelijk geen nodig hebben.

FlagWhere it livesWorks unattended
0 savedConnection profileYes, if the store is readable
1 agent-ownedSecret agent or keyringOnly if that agent is available
2 not-savedNowhereNo

Stel de vlaggen per geheim in in plaats van per verbinding. Eén verbinding kan een agent-eigen wachtwoord en een opgeslagen wachtwoordzin voor een privésleutel hebben.

Beslis op basis van wanneer de verbinding start

Als een ingelogde gebruiker de verbinding start, is agent-eigendom de verstandige standaard: de sleutelring wordt door de login ontgrendeld en het geheim staat nooit in een bestand. Als de verbinding omhoog moet voordat iemand inlogt, is agent-eigendom de verkeerde keuze, omdat er geen sessiesleutelring is om te ontgrendelen.

Dat is de hele beslissing. Al het andere is er een variant van.

Voor een dienst vóór het inloggen is een opslag op systeemniveau of een beveiligd sleutelbestand het ondersteunde patroon, en bestandsrechten worden de bescherming. Los het probleem niet op door het wachtwoord in een shellscript te plakken dat bij het opstarten draait.

Wat de sleutelring geeft en wat niet

Een sleutelring houdt het geheim buiten het verbindingsprofiel en bindt het aan een gebruikerssessie. Hij maakt het geheim niet beschikbaar voor een dienst zonder sessie, en hij versleutelt niets op de lijn. Dat zijn afzonderlijke eigenschappen die mensen vaak samenvoegen. Wat hij wel koopt, is een kleinere schadecirkel wanneer een profielbestand uitlekt.

De privésleutel waarnaar het profiel verwijst heeft eigen rechten nodig, ongeacht waar het wachtwoord leeft.

Diagnose zonder geheimen te dumpen

Verbindingsnamen, UUID's en vlaggen zijn meestal genoeg om een storing te verklaren. nmcli connection show somt het profiel op, en de geheime vlaggen vertellen je waar het wachtwoord vandaan had moeten komen.

Vermijd --show-secrets in tickets en chat. Zodra het geplakt is, is het een inloggegeven in een transcript.

Opslag is geen intrekking

Een geheim uit één sleutelring verwijderen maakt het inloggegeven niet ongeldig dat de externe operator al heeft geaccepteerd. Het intrekken van een account is een actie aan de serverkant, en lokale opslag is een aparte kwestie met een aparte eigenaar.

Beslis beide vóór het incident, niet tijdens. Een interactieve gebruikerverbinding en een dienst vóór het inloggen vragen verschillende antwoorden, en een gedeeld shellscript is geen van beide. De documentatie van NetworkManager over geheime vlaggen somt de waarden volledig op.

Gerelateerde artikelen