Saan Dapat Itago ng Linux ang Iyong Password sa VPN? Hindi sa Profile
Ang mga secret flag ng NetworkManager ang nagpapasya kung ang profile, isang keyring agent o wala ang may hawak ng password. Depende ang sagot sa kung kailan nagsisimula ang koneksyon.
Kailangang mabuhay ang password sa VPN sa isang lugar: sa profile ng koneksyon, sa keyring na binubuksan ng desktop, o wala talaga. Tinatawag ng NetworkManager na secret flag ang pagpipiliang iyon, at ang pagpili ng mali ang dahilan kung bakit gumagana ang koneksyon pagkatapos ng login at nabibigo bilang serbisyo. Ang flag ay isang linya ng configuration, at ito ang nagpapasya kung alin sa tatlong resulta ang makukuha mo.
Tatlong flag ang sumasaklaw sa halos lahat ng kaso, at ang desisyon ay tungkol sa kung kailan nagsisimula ang koneksyon.
Tatlong secret flag, tatlong pag-uugali
Ang flag na 0 ay nangangahulugang naiimbak ang secret kasama ng koneksyon, sa alinmang tindahan na may hawak ng profile. Ang flag na 1 ay ginagawa itong pag-aari ng agent: nagmumula ang secret sa isang secret agent tulad ng keyring ng desktop, at hinihingi ito ng NetworkManager sa activation. Ang flag na 2 ay nangangahulugang hindi naiimbak, kaya hindi kailanman isinusulat ang secret at kailangang ibigay sa bawat pagkakataon. Ang flag 4 ay nagmamarka ng secret bilang hindi kailangan, para sa mga koneksyong talagang wala namang kailangan.
| 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 |
Itakda ang mga flag bawat secret, hindi bawat koneksyon. Ang isang koneksyon ay maaaring may password na pag-aari ng agent at naka-imbak na passphrase ng pribadong key.
Magpasya batay sa kung kailan nagsisimula ang koneksyon
Kung ang naka-login na user ang nagsisimula ng koneksyon, ang pag-aari ng agent ang makatwirang default: binubuksan ng login ang keyring at hindi kailanman natitira ang secret sa isang file. Kung kailangang bumangon ang koneksyon bago mag-login ang sinuman, mali ang pag-aari ng agent, dahil walang session keyring na bubuksan.
Iyon ang buong desisyon. Ang lahat ng iba ay isang variant nito.
Para sa serbisyong bago ang login, ang sinusuportahang pattern ay isang tindahang pang-system o protektadong key file, at ang mga permiso ng file ang nagiging proteksyon. Huwag lutasin ang problema sa pagdikit ng password sa isang shell script na tumatakbo sa boot.
Ano ang ibinibigay ng keyring at ano ang hindi
Inilalayo ng keyring ang secret mula sa profile ng koneksyon at itinatali ito sa session ng user. Hindi nito ginagawang magagamit ang secret sa serbisyong walang session, at wala itong ine-encrypt sa wire. Magkahiwalay ang mga katangiang ito na kadalasang pinagsasama ng mga tao. Ang tunay nitong binibili ay mas maliit na saklaw ng pinsala kapag tumagas ang file ng profile.
Ang pribadong key na tinutukoy ng profile ay nangangailangan ng sarili nitong mga permiso, anuman ang kinaroroonan ng password.
Diagnostics na hindi nagtatapon ng mga secret
Karaniwang sapat ang mga pangalan ng koneksyon, UUID at flag para ipaliwanag ang isang pagkabigo. nmcli connection show naglista ng profile, at sinasabi ng mga secret flag kung saan dapat nagmula ang password.
Iwasan --show-secrets sa mga ticket at chat. Kapag nadikit na, ito ay isang credential sa isang transcript.
Ang pag-iimbak ay hindi pagpapawalang-bisa
Ang pag-alis ng secret mula sa isang keyring ay hindi nagpapawalang-bisa sa credential na tinanggap na ng remote operator. Ang pagpapawalang-bisa ng account ay aksyon sa panig ng server, at ang lokal na pag-iimbak ay hiwalay na usapin na may hiwalay na may-ari.
Magpasya sa dalawa bago ang insidente, hindi habang nangyayari. Ang interactive na koneksyon ng user at serbisyong bago ang login ay nangangailangan ng magkaibang sagot, at ang pinagsasaluhang shell script ay hindi alinman sa dalawa. Ang dokumentasyon ng NetworkManager tungkol sa mga secret flag ay naglilista ng lahat ng halaga.