Sådan deler du SSH-loginoplysninger sikkert med et link, der udløber

Nogen skal ind på en server i aften, og loginoplysningerne skal frem til vedkommende nu. Det er fristende at indsætte den private nøgle eller root-adgangskoden i Slack. Alle beskeder, som nøglen passerer, gemmer en kopi. Derfor er et engangslink med udløb den bedre vej: hemmeligheden hentes én gang, og så er den væk.

Et link er dog kun leveringen. Før du opretter et, skal du vælge de rigtige loginoplysninger at sende, afgrænse dem til opgaven og beslutte, hvordan du fjerner dem igen. Guiden dækker det hele, også spørgsmålet om, hvad der skal i et engangslink til at dele adgangsoplysninger til en server, og hvad der skal holdes ude.

Hvilke SSH-loginoplysninger deler du egentlig?

SSH-adgang kan bygge på fire forskellige ting, og de har vidt forskellige regler for deling.

Den bedste overdragelse er en, hvor intet hemmeligt flyttes. Har modtageren allerede et SSH-nøglepar, så bed om den offentlige nøgle, tilføj den til ~/.ssh/authorized_keys på den rigtige konto, og bed modtageren om at forbinde. Når du senere fjerner den ene linje, er adgangen slut.

Opret en særskilt nøgle til modtageren, hvis modtageren ikke har en og ikke kan lave en. Send aldrig din egen private nøgle, som du bruger til daglig. En nøgle, der er lavet til modtageren, kan afgrænses, logges og slettes uden at påvirke noget andet.

Brug hellere certifikater eller styret adgang til tilbagevendende behov. Skal den samme person have adgang igen og igen, er gentagne engangsoverdragelser det forkerte værktøj. Et SSH-certifikat med kort gyldighed eller et adgangsværktøj som Teleport eller Tailscale SSH giver dig et udløb, der er bygget ind i selve loginoplysningen i stedet for at være skruet på leveringen.

Afgræns loginoplysningerne, før du deler dem

Uanset hvad du sender, så gør det så lille, som opgaven tillader:

• Én konto, én vært. Tilføj nøglen til den tjenestekonto, der ejer arbejdet, ikke til root, og kun på den maskine, det drejer sig om.
• Begræns, hvad nøglen kan, med authorized_keys-indstillinger som from="203.0.113.5", no-port-forwarding eller en command=-wrapper, når opgaven er et enkelt script.
• Giv adgangskoden en holdbarhed. Deler du en adgangskode, så brug passwd -e eller platformens tilsvarende funktion, så modtageren skal skifte den ved første login, og planlæg at deaktivere kontoen på en fastsat dato.
• Skriv slutdatoen ned, før du sender noget. ”Når arbejdet er færdigt” er ikke en dato.

Sådan deler du SSH-loginoplysninger med et link, der udløber

1. Bekræft modtageren via en kanal, du allerede stoler på: sagen, en kendt e-mailtråd eller et opkald. De fleste loginoplysninger, der havner det forkerte sted, skyldes en adresse, der ligner den rigtige, eller et navn, som autoudfyldning har valgt.
2. Indsæt kun hemmeligheden i værktøjet til hemmelige engangslinks. For en privat nøgle betyder det hele PEM-blokken og intet andet. I LinkPilot krypteres teksten i din browser, før den gemmes, så tjenesten kun nogensinde har chifferteksten, og nøglen til at dekryptere den ligger i den del af URL'en, som browsere ikke sender til servere.
3. Sæt udløbet, så det passer til tidsvinduet. En time, hvis modtageren venter på den, 24 timer, hvis modtageren er i en anden tidszone, og syv dage kun, når der er en reel grund. Linket destrueres også første gang, det åbnes, så udløbet er sikkerhedsnettet, ikke den vigtigste kontrol.
4. Tilføj en adgangssætning med en Pro-konto, når loginoplysningerne er følsomme, og giv adgangssætningen videre via en anden kanal. På Pro viser revisionsloggen også, hvornår indholdet blev vist.
5. Send linket med én linje om formålet og ingen forbindelsesoplysninger.
6. Send forbindelsesoplysningerne i en separat besked: vært eller adresse, port, brugernavn og godkendelsesmetode. Ingen af dem er hemmelige hver for sig, men sammen med nøglen udgør de hele loginet.

Melder linket, at det allerede er åbnet, og siger modtageren, at det ikke var vedkommende selv, så diskuter det ikke. Betragt loginoplysningerne som kompromitterede, fjern nøglen eller skift adgangskoden, og opret nye.

Et engangslink til at dele adgangsoplysninger til en server

Spørgsmålet om, hvad der hører hjemme i hemmeligheden, dukker op hver gang. En god regel er, at linket indeholder det, en angriber ikke kan gætte, og at den almindelige besked indeholder det, angriberen kan.

I engangslinket:

• Den private nøgle eller den midlertidige adgangskode
• En adgangssætning til nøglen, hvis der blev sat en, da den blev oprettet
• Intet andet

I en almindelig besked, sendt for sig:

• Værtsnavn eller IP-adresse og port
• Den konto, der skal logges ind med
• Om der skal bruges en nøgle eller en adgangskode
• Værtsnøglens fingeraftryk, så modtageren kan bekræfte serveren ved den første forbindelse
• En kort note om, hvad adgangen er til, og hvornår den slutter

Hold skærmbilleder og terminallogs ude af begge. Et skærmbillede af en aktiv session viser ofte tokens, interne adresser og andre brugernavne, som det aldrig var meningen skulle sendes videre.

Hjælp modtageren med at gemme nøglen sikkert

En sikker overdragelse fejler alligevel, hvis nøglen ender i Overførsler med rettigheder, så alle kan læse den. Send disse instruktioner sammen med forbindelsesoplysningerne:

# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5

Bed modtageren om først at åbne det hemmelige link, når nøglen skal bruges, på en enhed, modtageren selv styrer, og over en forbindelse, modtageren stoler på. Åbner man det på en delt maskine ”for at se, om det virker”, efterlader det en kopi i maskinens udklipsholderhistorik.

Bekræft, og luk så vinduet

Mens adgangsvinduet stadig er åbent, skal modtageren teste præcis den forbindelse, der skal bruges, og bekræfte, at opgaven kører. Udvid ikke rettighederne for at få en test til at lykkes. Ret afgrænsningen i stedet.

Når arbejdet er færdigt:

1. Fjern den offentlige nøgle fra authorized_keys, deaktiver kontoen, eller lad certifikatet udløbe som planlagt.
2. Roter alt, der fulgte med loginoplysningerne, også en midlertidig adgangskode, der skulle have været skiftet ved første login, men ikke blev det.
3. Gennemgå auth.log eller din SSH-revisionskilde for forbindelser uden for det aftalte tidsrum eller fra uventede adresser.
4. Skriv ned, hvem der havde hvad, fra hvornår til hvornår. Notatet bliver, loginoplysningerne gør ikke.

Linkets udløb begrænser, hvor længe hemmeligheden kunne hentes. Udløbet på selve loginoplysningen begrænser, hvor længe den kan bruges. Du vil have begge dele, og det er det andet, folk glemmer.

Læs også

• Sikker linkdeling for udviklere
• Sådan deler du API-nøgler sikkert
• Links med udløb: hemmeligheden destrueres, den bliver ikke bare omdirigeret
• Linkscannere og engangshemmeligheder