Alisin ang passphrase ng susi o panatilihin ito? Ang kopyang ginagawa mo

Ang naka-encrypt na pribadong susi at ang hindi naka-encrypt ay may parehong materyal ng susi. Hindi lumilikha ng bagong pagkakakilanlan ang conversion, hindi nire-reset ang isang VPN account at hindi ginagawang di-wasto ang lumang file. Nagsusulat ito ng pangalawang kopya, at ang kopyang iyon ay may ibang panganib habang nakapahinga.

Kung sulit ang palitan ay depende sa kung saan maninirahan ang file at kung sino ang makakabasa nito.

Ano ang talagang binabago ng conversion

Bago ang conversion, pinoprotektahan ang susi ng passphrase na ibinibigay ng operator. Pagkatapos ng conversion, pinoprotektahan ito ng mga pahintulot ng filesystem at ng anumang kontrol sa pag-access sa paligid ng file. Hindi nagbago ang kriptograpiya; nagbago ang bilang ng mga bagay sa pagitan ng isang umaatake at ng susi. Iyon ang buong paghahambing.

Ginagawang konkretong ang pagkakaiba ng isang talahanayan.

Walang anyo ang awtomatikong mas ligtas. Nabibigo sila sa magkaibang paraan, at isa lang sa mga paraang iyon ang nag-iiwan ng entry sa log.

Kailan mas mabuting panatilihin ang passphrase

Kung ang isang suportadong kliyente ay makakahiling ng passphrase o makakakuha nito mula sa isang aprubadong imbakan ng sikreto, walang nabibili ang conversion. Isang kopya, isang hangganan ng proteksyon at isang file na mas kaunti ang iyong pinapanatili. Karamihan sa mga VPN kliyente na tumatanggap ng PEM na susi ay kayang gawin ito.

Ang conversion ay mali rin kapag pinaghahatian ng isang team ang susi. Ang isang hindi naka-encrypt na file sa isang shared host ay nagiging kredensyal na maaaring kopyahin ng sinumang may access sa shell.

Kailan makatwiran ang isang hindi naka-encrypt na kopya

May mga serbisyong hindi makakahiling, may mga container na nag-mount ng mga sikreto bilang read-only, at may mga appliance na nagbabasa ng file ng susi sa boot nang walang interactive na landas. Sa mga kasong iyon, ang isang hindi naka-encrypt na susi sa loob ng maayos na pinaghihigpitang direktoryo ay maaaring ang suportadong disenyo. Ang katwiran ay ang kapaligiran, hindi ang kaginhawahan.

Kung hindi mo masabi kung sino ang makakabasa ng file at bakit, ang sagot ay hindi.

Ang utos at ang matatalim na gilid nito

Para sa isang file-based na susi na sinusuportahan ng OpenSSL 3.5, ang pkey reference ay nagdodokumento ng pag-alis ng passphrase at isang interactive na prompt kapag naka-encrypt ang input at walang ibinibigay na pinagmulan ng password. Maikli ang pinakamaliit na anyo, at madaling isagawa ito nang walang ingat.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

Tatlong matatalim na gilid. Hindi atomiko ang I/O ng output file, kaya ang isang umiiral na output path ay maaaring maputol sa gitna ng pagsulat. Huwag gamitin ang input path bilang output, at huwag mag-eksperimento sa nag-iisang protektadong kopya. Ilagay ang passphrase sa prompt sa halip na sa command line, kung saan napupunta ito sa history ng shell.

Suriin ang resulta bago baguhin ang anumang VPN configuration: openssl pkey -in new-private-key.pem -pubout ay dapat mag-print ng parehong pampublikong susi na mayroon ka noon.

Ano ang hindi ginagawa ng conversion

Hindi nito binabawi ang naka-encrypt na kopya, na umiiral pa rin kahit saan mo man ito iniwan. Hindi nito binabago ang password ng VPN account o ang sertipiko. At hindi nito naaayos ang isang paglantad na nangyari na. Kung tumagas ang isang susi, ang solusyon ay pagpapalit at pag-withdraw sa panig ng server, hindi isang lokal na pagbabago ng format.

Sadyang tanggalin ang intermediate na file, at tiyakin na ang path na tinatanggal mo ay ang ginawa mo.