Unde ar trebui Linux să stocheze parola VPN? Nu în profil
Flag-urile de secret ale NetworkManager decid dacă parola este ținută de profil, de un agent de inel de chei sau de nimeni. Răspunsul depinde de momentul în care conexiunea pornește.
Parola VPN trebuie să trăiască undeva: în profilul conexiunii, într-un inel de chei pe care desktopul îl deblochează sau nicăieri. NetworkManager numește această alegere flag de secret, iar alegerea celui greșit este motivul pentru care o conexiune funcționează după autentificare și eșuează ca serviciu. Flag-ul este o linie de configurare și hotărăște care dintre cele trei rezultate îl obții.
Trei flag-uri acoperă aproape orice caz, iar decizia privește momentul în care conexiunea pornește.
Trei flag-uri de secret, trei comportamente
Un flag 0 înseamnă că secretul este salvat împreună cu conexiunea, în orice depozit care ține profilul. Un flag 1 îl face proprietatea agentului: secretul vine de la un agent de secrete precum un inel de chei de desktop, iar NetworkManager îl cere la activare. Un flag 2 înseamnă nesalvat, așa că secretul nu este scris niciodată și trebuie furnizat de fiecare dată. Flag-ul 4 marchează un secret ca nefiind necesar, pentru conexiunile care chiar nu au nevoie de niciunul.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Setează flag-urile pe fiecare secret, nu pe conexiune. O conexiune poate avea o parolă proprietatea agentului și o frază de acces a cheii private salvată.
Decide după momentul în care conexiunea pornește
Dacă un utilizator autentificat pornește conexiunea, proprietatea agentului este valoarea implicită rezonabilă: inelul de chei este deblocat la autentificare, iar secretul nu stă niciodată într-un fișier. Dacă conexiunea trebuie să pornească înainte ca cineva să se autentifice, proprietatea agentului este alegerea greșită, deoarece nu există niciun inel de chei de sesiune de deblocat.
Asta este toată decizia. Tot restul este o variantă a ei.
Pentru un serviciu dinainte de autentificare, modelul acceptat este un depozit la nivel de sistem sau un fișier de cheie protejat, iar permisiunile fișierului devin protecția. Nu rezolva problema lipind parola într-un script shell care rulează la pornire.
Ce oferă inelul de chei și ce nu
Un inel de chei ține secretul în afara profilului conexiunii și îl leagă de o sesiune de utilizator. Nu face secretul disponibil unui serviciu fără sesiune și nu criptează nimic pe fir. Sunt proprietăți separate pe care oamenii le contopesc des. Ce cumpără de fapt este o rază de prejudiciu mai mică atunci când un fișier de profil se scurge.
Cheia privată la care face referire profilul are nevoie de propriile permisiuni, indiferent unde trăiește parola.
Diagnosticare fără a vărsa secrete
Numele conexiunilor, UUID-urile și flag-urile sunt de obicei suficiente pentru a explica o defecțiune. nmcli connection show listează profilul, iar flag-urile de secret îți spun de unde trebuia să vină parola.
Evită --show-secrets în tichete și chat. Odată lipit, este o acreditare într-o transcriere.
Stocarea nu este revocare
Eliminarea unui secret dintr-un inel de chei nu invalidează acreditarea pe care operatorul la distanță a acceptat-o deja. Revocarea contului este o acțiune pe partea serverului, iar stocarea locală este o chestiune separată cu un proprietar separat.
Decide ambele înainte de incident, nu în timpul lui. O conexiune interactivă de utilizator și un serviciu dinainte de autentificare cer răspunsuri diferite, iar un script shell comun nu este nici una, nici alta. Documentația NetworkManager despre flag-urile de secret listează valorile în întregime.