Verwyder ’n sleutelfrase of behou dit? Die kopie wat jy skep
’n Onversleutelde sleutellêer hou dieselfde geheim agter swakker beskerming. Vergelyk die risiko in rus voordat jy omskakel, en weet wat dit nie ongedaan maak nie.
’n Versleutelde private sleutel en ’n onversleutelde een hou dieselfde sleutelmateriaal. Omskakeling skep nie ’n nuwe identiteit nie, stel nie ’n VPN-rekening terug nie en maak nie die ou lêer ongeldig nie. Dit skryf ’n tweede kopie, en daardie kopie dra ’n ander risiko in rus.
Of die ruil die moeite werd is, hang daarvan af waar die lêer sal woon en wie dit kan lees.
Wat omskakeling werklik verander
Voor omskakeling word die sleutel beskerm deur ’n sleutelfrase wat die operateur verskaf. Na omskakeling word dit beskerm deur lêerstelseltoestemmings en watter toegangsbeheer ook al die lêer omring. Die kriptografie het nie verander nie; die aantal dinge tussen ’n aanvaller en die sleutel het. Dit is die hele vergelyking.
’n Tabel maak die verskil konkreet.
| 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 |
Nie een vorm is outomaties veiliger nie. Hulle faal op verskillende maniere, en net een van daardie maniere laat ’n log-inskrywing.
Wanneer dit beter is om die sleutelfrase te behou
As ’n ondersteunde kliënt om die sleutelfrase kan vra of dit by ’n goedgekeurde geheime stoor kan haal, koop omskakeling niks. Jy hou een kopie, een beskermingsgrens en een minder lêer om na te spoor. Die meeste VPN-kliënte wat PEM-sleutels aanvaar, kan dit doen.
Omskakeling is ook die verkeerde skuif wanneer ’n span die sleutel deel. ’n Onversleutelde lêer op ’n gedeelde gasheer word ’n geloofsbrief wat enigiemand met shell-toegang kan kopieer.
Wanneer ’n onversleutelde kopie geregverdig is
Sommige dienste kan nie vra nie, sommige houers monteer geheime leesalleen, en sommige toestelle lees ’n sleutellêer by die opstart sonder ’n interaktiewe pad. In daardie gevalle kan ’n onversleutelde sleutel in ’n behoorlik beperkte gids die ondersteunde ontwerp wees. Die regverdiging is die omgewing, nie gerief nie.
As jy nie kan sê wie die lêer kan lees en waarom nie, is die antwoord nee.
Die opdrag en sy skerp kante
Vir ’n lêergebaseerde sleutel wat deur OpenSSL 3.5 ondersteun word, die pkey-verwysing dokumenteer die verwydering van die sleutelfrase en ’n interaktiewe vraag wanneer die invoer versleutel is en geen wagwoordbron verskaf word nie. Die minimale vorm is kort, en dit is maklik om dit onversigtig te hardloop.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemDrie skerp kante. Uitvoerlêer-I/O is nie atomies nie, so ’n bestaande uitvoerpad kan middel-weg afgekap word. Moenie die invoerpad as die uitvoer gebruik nie, en moenie op die enigste beskermde kopie eksperimenteer nie. Voer die sleutelfrase by die opdrag in eerder as op die opdragreël, waar dit in die shell-geskiedenis beland.
Kontroleer die resultaat voordat jy enige VPN-konfigurasie verander: openssl pkey -in new-private-key.pem -pubout moet dieselfde publieke sleutel druk wat jy voorheen gehad het.
Wat omskakeling nie doen nie
Dit herroep nie die versleutelde kopie nie, wat steeds bestaan waar jy dit ook al gelaat het. Dit verander nie die VPN-rekeningwagwoord of die sertifikaat nie. En dit herstel nie ’n blootstelling wat reeds gebeur het nie. As ’n sleutel uitgelek het, is die oplossing vervanging en intrekking aan die bedienerkant, nie ’n plaaslike formaatverandering nie.
Verwyder die tussenlêer doelbewus, en bevestig dat die pad wat jy verwyder die een is wat jy geskep het.