Verhoed dat NetworkManager ’n gestoorde VPN-wagwoord wys
Vra elke keer, gee dit aan ’n sleutelring, of hou ’n lêer wat net vir root toeganklik is. Elke keuse het ’n ander blootstelling, en die wagwoord-vlag moet daarby pas.
NetworkManager kan ’n VPN-wagwoord hou sodat die verbinding opkom sonder dat iemand dit intik, en dit kan daardie waarde terugwys deur die redigeerder of deur nmcli --show-secrets. Drie eienaarskapmodelle is beskikbaar, en die wysgedrag is net ’n simptoom van watter een jy gekies het. Kies eers die model en stel dan die vlag wat daarmee pas, eerder as om ’n veld met ’n plekhouer weg te steek wat die volgende persoon sal verwar.
Drie eienaarskapmodelle
Die eerste model vra elke keer. Niks word gestoor nie, die geheim bestaan net vir die duur van die aktivering, en enigiemand wat die verbinding begin, moet die wagwoord ken. Dit is die minste gerieflike opsie en die maklikste een om te verdedig.
Die tweede gee die geheim aan ’n sleutelring wat deur die gebruiker besit word. Die agent ontsluit wanneer die sessie begin en voorsien die waarde op aanvraag, wat dit uit die verbindingslêer hou maar die verbinding aan daardie gebruiker se sessie koppel. Twee voorwaardes volg: die agent moet loop, en dit moet ontsluit wees.
Die derde stoor ’n beskermde geloofsbrief vir ’n stelselverbinding. Dit oorleef herlaai en werk voordat enigiemand aanmeld, en in ruil daarvoor lê die waarde op skyf wat deur lêertoestemmings eerder as deur enkripsie beskerm word.
Elke model is redelik in die regte konteks. Die fout is om hulle te meng, want so eindig ’n skootrekenaar met ’n geheim op twee plekke en geen duidelike antwoord oor watter een gesaghebbend is nie. Skryf neer watter model ’n profiel gebruik. Een reël in die span se werkboek spaar die volgende persoon daarvan om ’n vierde plek te bedink om te kyk.
Lees die huidige toestand voordat jy dit verander
Kyk na die profiel en na die geheimtoestand as die gebruiker wat die verbinding bestuur. Die tweede opdrag is die een wat vir jou sê of die waarde werklik leesbaar is.
nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnection’n Sleutellêer in daardie gids word gewoonlik deur root besit met modus 600. Dit hou gewone gebruikers uit, en dit hou root nie uit nie, wat saak maak wanneer dieselfde masjien gedeel word of wanneer ’n rugsteun as root loop.
Lêertoestemmings is ’n grens, nie enkripsie nie. Enigiemand wat die lêer as root kan lees, het die wagwoord in gewone teks. Dit is ’n aanvaarbare ruil vir ’n onbewaakte bediener en ’n swak een vir ’n gedeelde werkstasie. Om dit een keer neer te skryf, voorkom ’n lang argument oor of die waarde beskerm word.
Wat elke vlagwaarde doen
Die VPN-geheim dra ’n eienskap flags, en die waardes is nie uit die nommers alleen intuïtief nie.
| 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 |
Die werklike gedrag hang ook van die plugin en van of ’n agent loop, so beskou die tabel as die kontrak en die waargenome gedrag as die ding wat jy verifieer. ’n Waarde wat op een lessenaar werk, kan anders optree op ’n bediener sonder sessie. Daardie gaping is waar die meeste verwarrende kaartjies lê.
Stel die eienskap eksplisiet eerder as om ’n reël te skrap en te hoop. ’n Afwesige vlag is nie ’n beleid nie, en die volgende pakketopdatering kan dit invul met iets wat jy nie bedoel het nie.
Pas die model by wanneer die verbinding begin
As die verbinding net ooit begin terwyl ’n gebruiker aangemeld is, pas agent-eienaarskap goed en hou dit die geheim uit die lêer. As dit by die opstart begin, voordat enige sessie bestaan, kan ’n agent jou nie help nie.
Dit is die hele besluit vir die meeste masjiene. Dit verduidelik ook ’n klas verwarrende verslae waar die verbinding interaktief werk en na ’n herlaai misluk. Die vlag het nooit verander nie; die konteks het.
Vir die onbewaakte geval is ’n beperkte lêer wat deur root besit word of ’n goedgekeurde geloofsbriefbron die praktiese antwoord. Hou dit uit die verbindingsprofiel as daardie profiel ooit uitgevoer of na ’n ander masjien gekopieer word.
As die waarde al sigbaar was, roteer dit
Om ’n vlag te verander, laat die wagwoord self onaangeraak. ’n Waarde wat in ’n skermkiekie, in shell-geskiedenis, in ’n bondel wat na ondersteuning gestuur is, of in ’n lêer wat ander gebruikers kon oopmaak opgeduik het, moet as bekend beskou word.
Verander dit op die bediener, herstel dan die kliënt en beëindig enige sessie wat met die ou een geverifieer het. Om die plaaslike verbinding te skrap, herroep niks aan die ander kant nie, en dit is die deel wat mense mis.
Hou dan op om die wagwoord op die opdragreël te sit. Dit beland in shell-geskiedenis en kan in ’n proseslys verskyn; gebruik eerder die interaktiewe vra of die agent.
Verifieer deur weer te koppel
Herhaal die opdrag wat die geheim gewys het en bevestig dat die veld nie meer gedruk word nie. Koppel dan af en weer aan, en herlaai as die verbinding outomaties begin, want die interessante fout verskyn net wanneer die sessiekonteks verander.
As die geheim steeds opduik, voorsien ’n ander profiel of ’n ander agent dit. Ondersoek die aktiewe verbinding en die sleutelring in plaas daarvan om lêers te skrap totdat die simptoom skuif.