Fjerne en nøkkelpassfrase eller beholde den? Kopien du oppretter
En ukryptert nøkkelfil oppbevarer samme hemmelighet bak svakere beskyttelse. Sammenlign risikoen i ro før du konverterer, og vit hva det ikke gjør om.
En kryptert privat nøkkel og en ukryptert en inneholder samme nøkkelmateriale. Konvertering lager ikke en ny identitet, tilbakestiller ikke en VPN-konto og ugyldiggjør ikke den gamle filen. Den skriver en andre kopi, og den kopien bærer en annen risiko i ro.
Om byttet er verdt det avhenger av hvor filen skal ligge og hvem som kan lese den.
Hva konvertering faktisk endrer
Før konvertering beskyttes nøkkelen av en passfrase som operatøren oppgir. Etter konvertering beskyttes den av filsystemtillatelser og all tilgangskontroll rundt filen. Kryptografien er ikke endret; antallet ting mellom en angriper og nøkkelen er. Det er hele sammenligningen.
En tabell gjør forskjellen konkret.
| 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 |
Ingen av formene er automatisk sikrere. De feiler på ulike måter, og bare én av de måtene etterlater en loggoppføring.
Når det er bedre å beholde passfrasen
Hvis en støttet klient kan spørre etter passfrasen eller hente den fra et godkjent hemmelighetslager, kjøper konvertering ingenting. Du beholder én kopi, én beskyttelsesgrense og én fil mindre å følge med på. De fleste VPN-klienter som godtar PEM-nøkler kan gjøre dette.
Konvertering er også feil trekk når et team deler nøkkelen. En ukryptert fil på en delt vert blir en legitimasjon som alle med shell-tilgang kan kopiere.
Når en ukryptert kopi er berettiget
Noen tjenester kan ikke spørre, noen containere monterer hemmeligheter skrivebeskyttet, og noen enheter leser en nøkkelfil ved oppstart uten en interaktiv vei. I slike tilfeller kan en ukryptert nøkkel i en riktig begrenset mappe være det støttede designet. Begrunnelsen er miljøet, ikke bekvemmelighet.
Hvis du ikke kan si hvem som kan lese filen og hvorfor, er svaret nei.
Kommandoen og dens skarpe kanter
For en filbasert nøkkel som støttes av OpenSSL 3.5, pkey-referansen dokumenterer fjerning av passfrasen og en interaktiv forespørsel når inndataene er kryptert og ingen passordkilde er oppgitt. Den minimale formen er kort, og den er lett å kjøre uforsiktig.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemTre skarpe kanter. I/O for utdatafilen er ikke atomisk, så en eksisterende utdatasti kan bli avskåret midt i skrivingen. Ikke bruk inndatastien som utdata, og ikke eksperimenter på den eneste beskyttede kopien. Skriv inn passfrasen ved forespørselen i stedet for på kommandolinjen, der den havner i shell-historikken.
Kontroller resultatet før du endrer noen VPN-konfigurasjon: openssl pkey -in new-private-key.pem -pubout skal skrive ut den samme offentlige nøkkelen som du hadde før.
Hva konvertering ikke gjør
Den tilbakekaller ikke den krypterte kopien, som fortsatt finnes der du forlot den. Den endrer ikke VPN-kontoens passord eller sertifikatet. Og den reparerer ikke en eksponering som allerede har skjedd. Hvis en nøkkel er lekket, er løsningen utskifting og tilbakekalling på serversiden, ikke en lokal formatendring.
Slett mellomfilen med vilje, og bekreft at stien du sletter er den du opprettet.