Ko zapravo vidi vašu SSH lozinku na nepouzdanoj VPN mreži?

Provedite SSH sesiju kroz VPN kojim ne upravljate vi, a lozinka i dalje pripada SSH serveru, ne mreži između. Ako je prijenos do provjerenog hosta ispravno zaštićen, pasivni promatrač na tom putu ne dobiva lozinku u čitljivu obliku. Promijenite li ipak jedan uvjet, odgovor se mijenja: neprovjeren host, oslabljen popis šifri ili kompromitirana radna stanica daju različite ishode. Provedite provjere u nastavku po redu i svaku tretirajte kao uvjet zaustavljanja.

Imenujte primatelja prije nego što bilo što otkucate

Polje lozinke putuje unutar poruke za autentifikaciju, a ta poruka putuje unutar šifriranog prijenosa. Povjerljivost je svojstvo prijenosa, što znači da ovisi o tome je li zaštita dogovorena i je li dogovorena s hostom koji ste namjeravali. Ljudi preskaču upravo tu drugu polovicu. Veza šifrirana prema varalici istodobno je povjerljiva i beskorisna. Prijava na VPN ne dokazuje ništa o SSH hostu, a ugled pružatelja nije zamjena za provjeru ključa.

Držite dva smjera odvojeno u glavi. Ključ hosta odgovara na pitanje kojem ste serveru došli. Autentifikacija lozinkom ili ključem odgovara na pitanje kojeg korisnika server prihvaća. Poboljšanje drugoga nikada ne popravlja prvo.

Provjerite identitet hosta, zapis i pregovaranje

Počnite na klijentu sa zapisom koji već imate. Objavljeni otisak uspoređen s pouzdanim izvorom i unos u known_hosts koji još uvijek odgovara daju vam jedini dokaz koji je važan prije početka autentifikacije.

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

Na strani servera ispišite otiske koje namjeravate objaviti umjesto da ih kopirate iz sjećanja. Distribucija izvan kanala upravo je poanta; otisak zalijepljen iz istog kanala razgovora kao i ime hosta dokazuje samo da su oba došla s istog mjesta.

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

Dogovoreni algoritmi dolaze iz presjeka dviju strana. Ako konfiguracija klijenta prikiva zastarjelu razmjenu ključeva da bi dosegnula stari uređaj, taj se izbor primjenjuje na svaki host s kojim razgovara, pa ga ograničite na taj host umjesto globalno.

Pročitajte metode koje server zapravo prihvaća

Znati koje metode autentifikacije server dopušta govori vam čemu lozinka uopće služi. Host koji prihvaća samo javne ključeve nema razmjenu lozinki koju treba štititi, a host koji još prihvaća lozinke zaslužuje namjernu odluku, a ne naslijeđenu zadanu vrijednost.

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

Prebacivanje korisnika na autentifikaciju ključem uklanja lozinku tog korisnika iz te razmjene. To ne čini kompromitiranu radnu stanicu sigurnom i ne čini nepouzdanu udaljenu sesiju bezopasnom. To su različiti rizici s različitim kontrolama. Odlučite i o prosljeđivanju agenta. Prosljeđivanje agenta na nepouzdan host daje tom hostu mogućnost korištenja vaših ključeva dok sesija traje, što je veća izloženost od pitanja o lozinci s kojim je sve počelo.

Tretirajte upozorenje o ključu hosta kao korak incidenta

Kada klijent upozori da se identifikacija hosta promijenila, zaustavite se i provjerite kroz kanal koji ne prolazi istim mrežnim putem. Usporedite otisak s konzolom servera ili s operaterom koji ga je ponovno izgradio. Brisanje starog unosa da bi se upozorenje ušutkalo jedina je radnja koju treba odbiti. Ono odbacuje dokaze i pretvara moguće presretanje u običnu prijavu.

Ako je host legitimno ponovno izgrađen, uklonite zastarjeli unos tek nakon što se potvrdi novi otisak, zatim se ponovno povežite i ponovno provjerite pregovaranje. Zabilježite promjenu s datumom i razlogom, jer će sljedeća osoba vidjeti isto upozorenje i mora znati da je riješeno.

Što ovaj priručnik ne pokriva

VPN operater koji promatra promet nije isto što i softver s lokalnim privilegijama na vašem računalu. Kompromitacija krajnje točke, neprijateljski dodatak pregledniku ili snimač tipkovnice nalaze se ispod svega što SSH može pregovarati i nikakav tunel to ne mijenja. Ako je radna stanica sumnjiva, slijedite proces za incidente umjesto da testirate tajnost ponovnim povezivanjem kroz drugi izlaz. Ponovno povezivanje dokazuje da se mrežni put promijenio i ništa o krajnjoj točki.

Završite s uobičajenim slučajem: provjeren host, zaštićen prijenos, metoda autentifikacije koju ste namjerno odabrali i nikakvo prosljeđivanje koje vam nije trebalo. Ta kombinacija odgovor je na pitanje iz naslova i ona su četiri odluke, a ne jedna.