Hvem ser egentlig din SSH-adgangskode på en utroværdig VPN?

Send en SSH-session over en VPN, du ikke selv driver, og adgangskoden tilhører stadig SSH-serveren, ikke netværket imellem. Hvis transporten til en verificeret vært er ordentligt beskyttet, får en passiv iagttager på den vej ikke adgangskoden i læsbar form. Men ændr én betingelse, og svaret ændrer sig: en uverificeret vært, en svækket cipher-liste eller en kompromitteret arbejdsstation giver alle forskellige udfald. Kør kontrollerne nedenfor i rækkefølge, og behandl hver af dem som en stopbetingelse.

Navngiv modtageren, før du taster noget

Adgangskodefeltet rejser inde i en autentifikationsmeddelelse, og den meddelelse rejser inde i den krypterede transport. Fortrolighed er en egenskab ved transporten, hvilket betyder, at den afhænger af, at beskyttelse er forhandlet, og af, at den er forhandlet med den vært, du havde til hensigt. Det er netop den anden halvdel, folk springer over. En forbindelse, der er krypteret til en bedrager, er fortrolig og ubrugelig på samme tid. VPN-loginet beviser intet om SSH-værten, og udbyderens omdømme er ikke en erstatning for nøglekontrollen.

Hold de to retninger adskilt i hovedet. Værtens nøgle svarer på, hvilken server du nåede. Adgangskode- eller nøgleautentifikation svarer på, hvilken bruger serveren accepterer. At forbedre det andet reparerer aldrig det første.

Kontrollér værtens identitet, posten og forhandlingen

Begynd på klienten med den post, du allerede har. Et offentliggjort fingeraftryk sammenlignet med en betroet kilde og en known_hosts-post, der stadig passer, giver dig det eneste bevis, der betyder noget, før autentifikationen begynder.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

På serversiden skal du udskrive de fingeraftryk, du agter at offentliggøre, i stedet for at kopiere dem fra hukommelsen. At distribuere dem uden om kanalen er hele pointen; et fingeraftryk klistret ind fra samme chatkanal som værtsnavnet beviser kun, at begge kom samme sted fra.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

De forhandlede algoritmer kommer fra fællesmængden af begge sider. Hvis en klientkonfiguration fastlåser en forældet nøgleudveksling for at nå en gammel enhed, gælder det valg for hver vært, den taler med, så begræns det til den vært i stedet for globalt.

Læs de metoder, serveren faktisk accepterer

At vide, hvilke autentifikationsmetoder en server tillader, fortæller dig, hvad adgangskoden overhovedet er til. En vært, der kun accepterer offentlige nøgler, har ingen adgangskodeudveksling at beskytte, og en vært, der stadig accepterer adgangskoder, fortjener en bevidst beslutning frem for en nedarvet standard.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

At skifte en bruger til nøgleautentifikation fjerner den brugers adgangskode fra den udveksling. Det gør ikke en kompromitteret arbejdsstation sikker, og det gør ikke en utroværdig fjernsession uskadelig. Det er forskellige risici med forskellige kontroller. Beslut også om agent-videresendelse. At videresende en agent til en utroværdig vært giver den vært mulighed for at bruge dine nøgler, så længe sessionen varer, og det er en større eksponering end det adgangskodespørgsmål, det hele startede med.

Behandl en advarsel om værtens nøgle som et incident-trin

Når klienten advarer om, at værtens identifikation er ændret, skal du stoppe og verificere gennem en kanal, der ikke går gennem samme netværksvej. Sammenlign fingeraftrykket med serverkonsollen eller med operatøren, der genopbyggede den. At slette den gamle post for at bringe advarslen til tavshed er den ene handling, du skal afvise. Den kasserer beviset og forvandler en mulig aflytning til et almindeligt login.

Hvis værten blev genopbygget legitimt, skal du først fjerne den forældede post, når det nye fingeraftryk er bekræftet, og derefter genoprette forbindelsen og kontrollere forhandlingen igen. Registrér ændringen med dato og årsag, fordi den næste person vil se den samme advarsel og har brug for at vide, at den er løst.

Hvad denne runbook ikke dækker

En VPN-operatør, der overvåger trafik, er ikke det samme som software med lokale rettigheder på din maskine. Kompromittering af endpointet, en fjendtlig browserudvidelse eller en keyboard-logger ligger under alt, hvad SSH kan forhandle, og ingen tunnel ændrer det. Hvis arbejdsstationen er mistænkelig, følg incidentprocessen i stedet for at teste hemmeligholdelse ved at genoprette forbindelsen gennem en anden udgang. Genoprettelse af forbindelsen beviser, at netværksvejen ændrede sig, og intet om endpointet.

Afslut med det almindelige tilfælde: verificeret vært, beskyttet transport, den autentifikationsmetode, du valgte med vilje, og ingen videresendelse, du ikke havde brug for. Den kombination er svaret på spørgsmålet i titlen, og det er fire beslutninger i stedet for én.