It VPN-wachtwurd moat earne wenje: yn it ferbiningsprofyl, yn in kaairing dy't it buroblêd ûntslút, of hielendal nearne. NetworkManager neamt dy kar in geheimflag, en de ferkearde kieze is wêrom't in ferbining nei oanmelding wurket en as tsjinst mislearret. It flag is ien rigel konfiguraasje, en it beslút hokker fan dy trije útkomsten jo krije.

Trije flaggen dekke hast elk gefal, en de beslissing giet oer wannear't de ferbining begjint.

Trije geheimflaggen, trije gedrachspatroanen

In flag fan 0 betsjut dat it geheim mei de ferbining bewarre wurdt, yn hokker opslach dan ek it profyl hâldt. In flag fan 1 makket it agent-eigendom: it geheim komt fan in geheimagent lykas in buroblêd-kaairing, en NetworkManager freget derom by aktivaasje. In flag fan 2 betsjut net-bewarre, dus it geheim wurdt nea skreaun en moat elke kear jûn wurde. Flag 4 markearret in geheim as net-ferplichte, foar ferbiningen dy't wier gjinien nedich hawwe.

FlagWhere it livesWorks unattended
0 savedConnection profileYes, if the store is readable
1 agent-ownedSecret agent or keyringOnly if that agent is available
2 not-savedNowhereNo

Set de flaggen per geheim ynstee fan per ferbining. Ien ferbining kin in agent-eigendom wachtwurd en in bewarre priveekaai-wachtfrase hawwe.

Beslis neffens wannear't de ferbining begjint

As in oanmelde brûker de ferbining begjint, is agent-eigendom de ferstannige standert: de kaairing wurdt troch de oanmelding ûntsletten en it geheim sit nea yn in bestân. As de ferbining opkomme moat foardat immen oanmeldt, is agent-eigendom de ferkearde kar, want der is gjin sesje-kaairing om te ûntsluten.

Dat is de hiele beslissing. Al it oare is in fariant dêrfan.

Foar in tsjinst foar oanmelding is in opslach op systeemnivo of in beskerme kaai-bestân it stipe patroan, en bestânsrjochten wurde de beskerming. Los it probleem net op troch it wachtwurd yn in shell-skript te plakken dat by it opstarten rint.

Wat de kaairing jout en wat net

In kaairing hâldt it geheim bûten it ferbiningsprofyl en bynt it oan in brûkerssesje. It makket it geheim net beskikber foar in tsjinst sûnder sesje, en it fersiferet neat op it netwurk. Dat binne aparte eigenskippen dy't minsken faak gearfiere. Wat it wol keapet, is in lytsere skea-radius as in profylbestân útlekt.

De priveekaai dêr't it profyl nei ferwiist, hat syn eigen rjochten nedich, ûnôfhinklik fan wêr't it wachtwurd wennet.

Diagnostyk sûnder geheimen út te stoarten

Ferbiningnammen, UUID's en flaggen binne meast genôch om in flater te ferklearjen. nmcli connection show listet it profyl op, en de geheimflaggen fertelle jo wêr't it wachtwurd wei komme moast.

Foarkom --show-secrets yn tickets en petearen. Ienris plakt, is it oanmeldgegevens yn in transkripsje.

Opslach is gjin ynlûken

It fuortheljen fan in geheim út ien kaairing makket de oanmeldgegevens net ûnjildich dy't de eksterne operator al akseptearre hat. It ynlûken fan in akkount is in aksje oan de serverkant, en lokale opslach is in aparte saak mei in aparte eigner.

Beslis beide foar it ynsidint, net ûnder it. In ynteraktive brûkersferbining en in tsjinst foar oanmelding hawwe ferskate antwurden nedich, en in dielde shell-skript is gjin fan beide. NetworkManager syn dokumintaasje oer geheimflaggen listet de wearden folslein op.

Relatearre artikelen