En SSH-nøgleadgangsfrase beskytter filen, ikke ruten

En backupdisk fra en gammel bærbar computer indeholder stadig en privat SSH-nøgle, og nogen spørger, om VPN beskytter den. Det gør den ikke, og det har den aldrig gjort. VPN beskytter en vej mellem to netværk; adgangsfrasen beskytter filen; agenten beskytter en kørende session. Tre forskellige mekanismer, tre forskellige fejlmåder, og en stjålet kopi bekymrer sig kun om de to første.

Adgangsfrasen hører til filen

En SSH-nøgleadgangsfrase krypterer det private nøglemateriale, mens det ligger stille. Den er ikke den kontoadgangskode, der sendes til serveren, og den er ikke den legitimationsoplysning, der bruges til at slutte sig til VPN. At forveksle dem fører til ændringer, der ikke håndterer eksponeringen.

OpenSSHs ssh-keygen-manual dækker håndtering af adgangsfraser, herunder kontakten -p, der sætter en ny adgangsfrase på en nøgle, der allerede findes.

For en eksisterende nøgle er kommandoens form enkel, og den omskriver filen:

ssh-keygen -p -f ~/.ssh/id_ed25519

Brug nøgleejerens godkendte vedligeholdelses- og gendannelsesproces, fordi dette er en skrivning, ikke en inspektion. Offentliggør ikke den private fil, og sæt ikke en rigtig adgangsfrase på en delt kommandolinje. En ændring af adgangsfrasen genkrypterer ikke en kopi, der blev taget tidligere. Noter den gamle kopis placering i sagen, så ejeren kan beslutte, om den skal ødelægges.

En kopi overlever den bærbare computer og tunnelen

Når en nøglefil først er kopieret, siger den bærbare computers aktive VPN-forbindelse ikke længere noget om den. Det, der betyder noget, er hvor godt selve filen er beskyttet, og hvilke servere der stadig stoler på den matchende offentlige nøgle.

At ændre adgangsfrasen på den aktuelle fil rører ikke kopien og fjerner ikke den samme offentlige nøgle fra authorized_keys på en server. Tilbagekaldelse og genkryptering er separate handlinger.

Så behandl en lækket privat nøgle som en identitetshændelse, ikke en netværkshændelse. Fjern eller udskift den accepterede nøgle gennem de servere og den tilmeldingsproces, der ejer den. At stoppe VPN begrænser én rute på ét tidspunkt; det er ikke tilbagekaldelse.

Oplåsning flytter hemmeligheden ind i en agent

En agent holder dekrypterede identiteter til senere godkendelse, så brugeren ikke skal skrive adgangsfrasen igen for hver forbindelse. Det er en brugervenlighedsfunktion med sin egen sikkerhedsgrænse.

ssh-agent kan begrænse, hvor længe en identitet forbliver indlæst, via sin -t-indstilling, og en indstilling for den enkelte identitet kan overtrumfe den grænse. Vælg politikken for den agent, du faktisk kører, i stedet for at antage, at en VPN-afbrydelse glemmer hver indlæst nøgle.

En proces, der kompromitteres, efter nøglen er låst op, er et andet problem end en stjålet krypteret fil. Videresendelse af agenten til en anden vært delegerer godkendelsesevnen uden at kopiere nøglefilen, så aktiver det kun for et godkendt behov.

Oplist, hvad agenten aktuelt holder, før og efter en ændring:

ssh-add -l

Ubemandede opgaver har brug for deres egen plan

En planlagt opgave kan ikke svare på en prompt. Den har brug for en godkendt ordning med maskinlegitimationsoplysninger, og at holde oplåsningshemmeligheden i samme mappe som nøglen, læsbar for samme konto, skaber ikke en anden grænse.

Arbejd med tjenesteejeren om understøttet hemmelighedslevering eller hardwarebaseret drift, og dæk fornyelse, fejl og gendannelse. Ønsket om et menneske ved tastaturet ændrer, hvordan en fejl ser ud sammenlignet med en vært, der starter uden nogen, der ser til.

Behold også serverens værtsidentitetskontrol og dens kontobegrænsninger. En VPN-rute giver dig en privat vej; den beviser ikke, at hver SSH-lytter, du kan nå, er den vært, du havde tænkt på. Registrer lytteren og værtsnøglens fingeraftryk i samme fortegnelse som selve nøglen.

Verificer grænserne hver for sig

Test hver grænse med sit eget spørgsmål. Åbner filen uden adgangsfrasen? Holder agenten stadig identiteten efter en afbrydelse? Accepterer serveren stadig den offentlige nøgle?

To kommandoer besvarer den første og den tredje:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Registrer filbeskyttelse, tilladt nøglebrug og fjernelse på serversiden som tre separate poster. En tunnel, en adgangsfrase og en agent vogter hver sin del af forholdet, og kun én af dem handler om netværket.