Stop NetworkManager med at vise en gemt VPN-adgangskode
Spørg hver gang, giv den til en nøglering, eller hold en fil, som kun root kan læse. Hvert valg har en forskellig eksponering, og adgangskodens flag skal passe til det.
NetworkManager kan holde en VPN-adgangskode, så forbindelsen kommer op, uden at nogen skriver den, og det kan vise værdien igen gennem editoren eller gennem nmcli --show-secrets. Der findes tre ejerskabsmodeller, og visningsadfærden er kun et symptom på, hvilken du valgte. Vælg modellen først, og sæt derefter det flag, der passer til den, i stedet for at skjule et felt med en pladsholder, som vil forvirre den næste person.
Tre ejerskabsmodeller
Den første model spørger hver gang. Intet gemmes, hemmeligheden findes kun, mens aktiveringen varer, og enhver, der starter forbindelsen, skal kende adgangskoden. Det er den mindst bekvemme løsning og den nemmeste at forsvare.
Den anden giver hemmeligheden til en nøglering, som brugeren ejer. Agenten låser op, når sessionen starter, og leverer værdien efter behov, hvilket holder den ude af forbindelsesfilen men binder forbindelsen til den brugers session. To betingelser følger: agenten skal køre, og den skal være låst op.
Den tredje gemmer en beskyttet legitimation til en systemforbindelse. Den overlever genstarter og virker, før nogen logger ind, og til gengæld ligger værdien på disken beskyttet af filrettigheder i stedet for kryptering.
Hver model er rimelig i den rigtige sammenhæng. Fejlen er at blande dem, og sådan ender en bærbar computer med en hemmelighed to steder og uden et klart svar på, hvilken der er autoritativ. Skriv ned, hvilken model en profil bruger. Én linje i teamets runbook sparer den næste person for at opfinde et fjerde sted at kigge.
Læs den aktuelle tilstand, før du ændrer den
Se på profilen og på hemmelighedens tilstand som den bruger, der administrerer forbindelsen. Den anden kommando er den, der fortæller dig, om værdien faktisk kan læses.
nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnectionEn nøglefil i den mappe ejes normalt af root med tilstand 600. Det holder almindelige brugere ude og holder ikke root ude, hvilket betyder noget, når maskinen deles, eller når en sikkerhedskopi kører som root.
Filrettigheder er en grænse, ikke kryptering. Enhver, der kan læse filen som root, har adgangskoden i klartekst. Det er en acceptabel handel for en server uden opsyn og en dårlig en for en delt arbejdsstation. At skrive det ned én gang forhindrer en lang diskussion om, hvorvidt værdien er beskyttet.
Hvad hver flagværdi gør
VPN-hemmeligheden har en egenskab flags, og værdierne er ikke intuitive ud fra tallene alene.
| Value | Meaning | Practical effect |
|---|---|---|
| 0 | No special flag | Secret is typically saved with the connection |
| 1 | Agent-owned | A keyring or secret agent supplies it |
| 2 | Not saved | Prompted at each activation |
| 4 | Not required | Connection proceeds without asking |
Den faktiske adfærd afhænger også af plugin'et og af, om der kører en agent, så betragt tabellen som kontrakten og den observerede adfærd som det, du verificerer. En værdi, der virker på én skrivebordsmaskine, kan opføre sig anderledes på en server uden session. Netop i det gab ligger de fleste forvirrende sager.
Sæt egenskaben eksplicit i stedet for at slette en linje og håbe. Et manglende flag er ikke en politik, og den næste pakkeopdatering kan udfylde det med noget, du ikke havde til hensigt.
Tilpas modellen til, hvornår forbindelsen starter
Hvis forbindelsen kun starter, mens en bruger er logget ind, passer agent-ejerskab godt og holder hemmeligheden ude af filen. Hvis den starter ved opstart, før nogen session findes, kan en agent ikke hjælpe dig.
Det er hele beslutningen for de fleste maskiner. Det forklarer også en klasse af forvirrende rapporter, hvor forbindelsen virker interaktivt og fejler efter en genstart. Flaget ændrede sig aldrig; sammenhængen gjorde.
I det uovervågede tilfælde er en begrænset root-ejet fil eller en godkendt legitimation-kilde det praktiske svar. Hold den ude af forbindelsesprofilen, hvis profilen nogensinde eksporteres eller kopieres til en anden maskine.
Hvis værdien allerede var synlig, skal du udskifte den
Ændring af et flag rører ikke selve adgangskoden. En værdi, der dukkede op i et skærmbillede, i shell-historikken, i en pakke sendt til support eller i en fil, som andre brugere kunne åbne, bør betragtes som afsløret.
Skift den på serveren, ret derefter klienten, og afslut enhver session, der godkendte med den gamle. Sletning af den lokale forbindelse tilbagekalder intet på den anden side, og det er den del, folk overser.
Hold derefter op med at sætte adgangskoden på kommandolinjen. Den ender i shell-historikken og kan dukke op i en procesliste; brug den interaktive prompt eller agenten i stedet.
Bekræft ved at genoprette forbindelsen
Gentag kommandoen, der viste hemmeligheden, og bekræft, at feltet ikke længere udskrives. Afbryd og genopret derefter forbindelsen, og genstart, hvis forbindelsen starter automatisk, fordi den interessante fejl først vises, når sessionssammenhængen ændres.
Hvis hemmeligheden stadig vises, er det en anden profil eller en anden agent, der leverer den. Undersøg den aktive forbindelse og nøgleringen i stedet for at slette filer, indtil symptomet flytter sig.