Hvem ser egentlig SSH-passordet ditt på en ikke-klarert VPN?

Rut en SSH-økt over en VPN du ikke selv drifter, og passordet tilhører fortsatt SSH-serveren, ikke nettet imellom. Hvis transporten til en verifisert vert er skikkelig beskyttet, får en passiv observatør på den veien ikke passordet i lesbar form. Men endre én betingelse, og svaret endres: en uverifisert vert, en svekket chifferliste eller en kompromittert arbeidsstasjon gir alle forskjellige utfall. Kjør kontrollene nedenfor i rekkefølge, og behandle hver av dem som en stoppbetingelse.

Navngi mottakeren før du taster noe

Passordfeltet reiser inne i en autentiseringsmelding, og den meldingen reiser inne i den krypterte transporten. Konfidensialitet er en egenskap ved transporten, som betyr at den avhenger av at beskyttelse er forhandlet, og av at den er forhandlet med den verten du hadde til hensikt. Det er nettopp den andre halvdelen folk hopper over. En tilkobling som er kryptert til en bedrager, er konfidensiell og ubrukelig på samme tid. VPN-innloggingen beviser ingenting om SSH-verten, og leverandørens omdømme er ikke en erstatning for nøkkelkontrollen.

Hold de to retningene adskilt i hodet. Vertens nøkkel svarer på hvilken server du nådde. Passord- eller nøkkelautentisering svarer på hvilken bruker serveren godtar. Å forbedre det andre reparerer aldri det første.

Kontroller vertens identitet, oppføringen og forhandlingen

Begynn på klienten med oppføringen du allerede har. Et publisert fingeravtrykk sammenlignet med en klarert kilde, og en known_hosts-oppføring som fortsatt passer, gir deg det eneste beviset som betyr noe før autentiseringen begynner.

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

På serversiden skriver du ut fingeravtrykkene du har tenkt å publisere i stedet for å kopiere dem fra minnet. Å distribuere dem utenom kanalen er hele poenget; et fingeravtrykk limt inn fra samme chatkanal som vertsnavnet beviser bare at begge kom fra samme sted.

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

De forhandlede algoritmene kommer fra snittet av begge sider. Hvis en klientkonfigurasjon fester en utdatert nøkkelutveksling for å nå en gammel enhet, gjelder det valget for hver vert den snakker med, så begrens det til den verten i stedet for globalt.

Les metodene serveren faktisk godtar

Å vite hvilke autentiseringsmetoder en server tillater forteller deg hva passordet i det hele tatt er til. En vert som bare godtar offentlige nøkler har ingen passordutveksling å beskytte, og en vert som fortsatt godtar passord fortjener en bevisst beslutning i stedet for en nedarvet standardverdi.

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

Å bytte en bruker til nøkkelautentisering fjerner den brukerens passord fra den utvekslingen. Det gjør ikke en kompromittert arbeidsstasjon sikker, og det gjør ikke en ikke-klarert fjernøkt uskadelig. Det er forskjellige risikoer med forskjellige kontroller. Bestem deg også for agentvideresending. Å videresende en agent til en ikke-klarert vert gir den verten mulighet til å bruke nøklene dine så lenge økten varer, og det er en større eksponering enn passordspørsmålet det hele startet med.

Behandle en advarsel om vertsnøkkel som et hendelsestrinn

Når klienten advarer om at vertens identifikasjon er endret, stopp og verifiser gjennom en kanal som ikke går gjennom samme nettverksvei. Sammenlign fingeravtrykket med serverkonsollen eller med operatøren som bygde den opp igjen. Å slette den gamle oppføringen for å tysne advarselen er den ene handlingen du bør nekte. Den kaster beviset og gjør en mulig avlytting om til en vanlig innlogging.

Hvis verten ble bygget opp igjen på lovlig vis, fjern den utdaterte oppføringen først etter at det nye fingeravtrykket er bekreftet, koble deretter til på nytt og kontroller forhandlingen igjen. Registrer endringen med dato og årsak, fordi neste person vil se den samme advarselen og trenger å vite at den er løst.

Hva denne kjøreboken ikke dekker

En VPN-operatør som overvåker trafikk er ikke det samme som programvare med lokale rettigheter på maskinen din. Kompromittering av endepunktet, en fiendtlig nettleserutvidelse eller en tastaturlogger ligger under alt SSH kan forhandle om, og ingen tunnel endrer det. Hvis arbeidsstasjonen er mistenkelig, følg hendelsesprosessen i stedet for å teste hemmelighold ved å koble til på nytt gjennom en annen utgang. Å koble til på nytt beviser at nettverksveien er endret, og ingenting om endepunktet.

Avslutt med det vanlige tilfellet: verifisert vert, beskyttet transport, autentiseringsmetoden du valgte med vilje, og ingen videresending du ikke trengte. Den kombinasjonen er svaret på spørsmålet i tittelen, og det er fire beslutninger i stedet for én.