NetworkManager kan hålla ett VPN-lösenord så att anslutningen kommer upp utan att någon skriver det, och det kan visa värdet igen via redigeraren eller via nmcli --show-secrets. Det finns tre ägarmodeller, och visningsbeteendet är bara ett symptom på vilken du valde. Välj modellen först och sätt sedan flaggan som passar den, i stället för att dölja ett fält med en platshållare som förvirrar nästa person.

Tre ägarmodeller

Den första modellen frågar varje gång. Inget lagras, hemligheten finns bara under aktiveringen, och den som startar anslutningen måste känna till lösenordet. Det är det minst bekväma alternativet och det enklaste att försvara.

Den andra lämnar hemligheten till en nyckelring som användaren äger. Agenten låser upp när sessionen börjar och levererar värdet på begäran, vilket håller det utanför anslutningsfilen men binder anslutningen till den användarens session. Två villkor följer: agenten måste köra, och den måste vara upplåst.

Den tredje lagrar en skyddad autentiseringsuppgift för en systemanslutning. Den överlever omstarter och fungerar innan någon loggar in, och i gengäld ligger värdet på disken skyddat av filrättigheter i stället för kryptering.

Varje modell är rimlig i rätt sammanhang. Felet är att blanda dem, och så slutar en bärbar dator med en hemlighet på två ställen och utan ett tydligt svar på vilken som är auktoritativ. Skriv ned vilken modell en profil använder. En rad i teamets runbook sparar nästa person från att hitta på ett fjärde ställe att titta på.

Läs det aktuella tillståndet innan du ändrar det

Titta på profilen och på hemlighetens tillstånd som den användare som hanterar anslutningen. Det andra kommandot är det som säger om värdet verkligen går att läsa.

nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnection

En nyckelfil i den katalogen ägs vanligtvis av root med läge 600. Det håller vanliga användare ute och håller inte root ute, vilket spelar roll när samma maskin delas eller när en säkerhetskopia körs som root.

Filrättigheter är en gräns, inte kryptering. Den som kan läsa filen som root har lösenordet i klartext. Det är ett acceptabelt byte för en server utan tillsyn och ett dåligt för en delad arbetsstation. Att skriva ned det en gång förhindrar en lång diskussion om huruvida värdet är skyddat.

Vad varje flaggvärde gör

VPN-hemligheten har egenskapen flags, och värdena är inte intuitiva enbart från siffrorna.

ValueMeaningPractical effect
0No special flagSecret is typically saved with the connection
1Agent-ownedA keyring or secret agent supplies it
2Not savedPrompted at each activation
4Not requiredConnection proceeds without asking

Det faktiska beteendet beror också på insticksmodulen och på om en agent körs, så behandla tabellen som kontraktet och det observerade beteendet som det du verifierar. Ett värde som fungerar på ett skrivbord kan bete sig annorlunda på en server utan session. Det är i den luckan de flesta förvirrande ärendena bor.

Sätt egenskapen uttryckligen i stället för att radera en rad och hoppas. En saknad flagga är ingen policy, och nästa paketuppdatering kan fylla den med något du inte avsåg.

Anpassa modellen till när anslutningen startar

Om anslutningen bara startar medan en användare är inloggad passar agentägande bra och håller hemligheten utanför filen. Om den startar vid uppstart, innan någon session finns, kan en agent inte hjälpa dig.

Det är hela beslutet för de flesta maskiner. Det förklarar också en klass förvirrande rapporter där anslutningen fungerar interaktivt och misslyckas efter en omstart. Flaggan ändrades aldrig; sammanhanget gjorde det.

För det obevakade fallet är en begränsad rootägd fil eller en godkänd autentiseringskälla det praktiska svaret. Håll den utanför anslutningsprofilen om profilen någon gång exporteras eller kopieras till en annan maskin.

Om värdet redan var synligt, byt ut det

Att ändra en flagga lämnar själva lösenordet orört. Ett värde som dykt upp i en skärmbild, i shell-historiken, i ett paket som skickats till supporten eller i en fil som andra användare kunde öppna bör betraktas som röjt.

Byt det på servern, reparera sedan klienten och avsluta varje session som autentiserades med det gamla. Att radera den lokala anslutningen återkallar ingenting på andra sidan, och det är den delen folk missar.

Sluta sedan att sätta lösenordet på kommandoraden. Det hamnar i shell-historiken och kan dyka upp i en processlista; använd den interaktiva uppmaningen eller agenten i stället.

Verifiera genom att ansluta igen

Upprepa kommandot som visade hemligheten och bekräfta att fältet inte längre skrivs ut. Koppla sedan från och anslut igen, och starta om om anslutningen startar automatiskt, eftersom det intressanta felet först visar sig när sessionssammanhanget ändras.

Om hemligheten fortfarande visas är det en annan profil eller en annan agent som levererar den. Inspektera den aktiva anslutningen och nyckelringen i stället för att radera filer tills symptomet flyttar sig.

Relaterade artiklar