Ĉu forigi pasfrazon de ŝlosilo aŭ konservi ĝin? La kopio, kiun vi kreas
Neĉifrita ŝlosildosiero tenas la saman sekreton malantaŭ pli malforta protekto. Komparu la riskon dum ripozo antaŭ ol konverti, kaj sciu, kion ĝi ne malfaras.
Ĉifrita privata ŝlosilo kaj neĉifrita tenas la saman ŝlosilan materialon. Konvertado ne kreas novan identecon, ne restarigas VPN-konton kaj ne malvalidigas la malnovan dosieron. Ĝi skribas duan kopion, kaj tiu kopio portas alian riskon dum ripozo.
Ĉu la interŝanĝo valoras, dependas de tio, kie la dosiero loĝos kaj kiu povas legi ĝin.
Kion konvertado efektive ŝanĝas
Antaŭ konvertado, la ŝlosilon protektas pasfrazo, kiun la operatoro provizas. Post konvertado, ĝin protektas permesoj de la dosiersistemo kaj iu ajn alirkontrolo ĉirkaŭ la dosiero. La kriptografio ne ŝanĝiĝis; la nombro da aferoj inter atakanto kaj la ŝlosilo ŝanĝiĝis. Tio estas la tuta komparo.
Tabelo igas la diferencon konkreta.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Neniu formo estas aŭtomate pli sekura. Ili malsukcesas laŭ malsamaj manieroj, kaj nur unu el tiuj manieroj lasas protokolan enskribon.
Kiam konservi la pasfrazon estas pli bone
Se subtenata kliento povas peti la pasfrazon aŭ preni ĝin el aprobita sekreta konservejo, konvertado aĉetas nenion. Vi tenas unu kopion, unu protektan limon kaj unu dosieron malpli por spuri. Plej multaj VPN-klientoj, kiuj akceptas PEM-ŝlosilojn, povas fari tion.
Konvertado ankaŭ estas malĝusta movo, kiam teamo dividas la ŝlosilon. Neĉifrita dosiero sur dividita gastiganto fariĝas identigilo, kiun iu ajn kun ŝela aliro povas kopii.
Kiam neĉifrita kopio estas pravigita
Iuj servoj ne povas peti, iuj ujoj muntas sekretojn nurlegeble, kaj iuj aparatoj legas ŝlosildosieron ĉe starto sen interaga vojo. En tiuj kazoj, neĉifrita ŝlosilo en taŭge limigita dosierujo povas esti la subtenata dezajno. La pravigo estas la medio, ne la komforto.
Se vi ne povas diri, kiu povas legi la dosieron kaj kial, la respondo estas ne.
La komando kaj ĝiaj akraj randoj
Por dosierbaza ŝlosilo subtenata de OpenSSL 3.5, la pkey-referenco dokumentas forigon de la pasfrazo kaj interagan inviton, kiam la enigo estas ĉifrita kaj neniu pasvorta fonto estas provizita. La minimuma formo estas mallonga, kaj facile ekzekuteblas senatente.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemTri akraj randoj. Enigo/eligo de la eliga dosiero ne estas atoma, do ekzistanta eliga vojo povas esti tranĉita meze de skribo. Ne uzu la enigan vojon kiel eligon, kaj ne eksperimentu kun la sola protektita kopio. Entajpu la pasfrazon ĉe la invito anstataŭ en la komanda linio, kie ĝi finiĝas en la ŝela historio.
Kontrolu la rezulton antaŭ ol ŝanĝi iun ajn VPN-agordon: openssl pkey -in new-private-key.pem -pubout devus presi la saman publikan ŝlosilon, kiun vi havis antaŭe.
Kion konvertado ne faras
Ĝi ne revokas la ĉifritan kopion, kiu ankoraŭ ekzistas kie ajn vi lasis ĝin. Ĝi ne ŝanĝas la pasvorton de la VPN-konto nek la atestilon. Kaj ĝi ne riparas elmetiĝon, kiu jam okazis. Se ŝlosilo likis, la solvo estas anstataŭigo kaj retiro ĉe la servila flanko, ne loka formatoŝanĝo.
Forigu la interan dosieron intence, kaj konfirmu, ke la vojo, kiun vi forigas, estas tiu, kiun vi kreis.