Kas iš tikrųjų mato jūsų SSH slaptažodį nepatikimoje VPN?

Nukreipkite SSH sesiją per VPN, kurio nevaldote patys, ir slaptažodis vis tiek priklauso SSH serveriui, o ne tarpinei tinklo daliai. Jei transportas iki patvirtinto hosto tinkamai apsaugotas, pasyvus stebėtojas tame kelyje negauna slaptažodžio skaitoma forma. Bet pakeiskite vieną sąlygą, ir atsakymas pasikeis: nepatvirtintas hostas, susilpnintas šifrų sąrašas ar sugadinta darbo stotis duoda skirtingus rezultatus. Atlikite toliau nurodytas patikras iš eilės ir kiekvieną laikykite stabdymo sąlyga.

Įvardykite gavėją prieš ką nors įvesdami

Slaptažodžio laukas keliauja autentifikavimo pranešimo viduje, o tas pranešimas keliauja šifruoto transporto viduje. Konfidencialumas yra transporto savybė, tai reiškia, kad jis priklauso nuo to, ar apsauga buvo suderėta ir ar ji buvo suderėta su tuo hostu, kurį turėjote omenyje. Būtent šią antrą pusę žmonės praleidžia. Ryšys, užšifruotas apsimetėliui, yra konfidencialus ir kartu bevertis. VPN prisijungimas nieko neįrodo apie SSH hostą, o teikėjo reputacija nepakeičia rakto patikros.

Laikykite abi kryptis atskirai galvoje. Hosto raktas atsako į klausimą, į kurį serverį patekote. Slaptažodžio ar rakto autentifikavimas atsako į klausimą, kurį naudotoją serveris priima. Antrojo pagerinimas niekada nepataiso pirmojo.

Patikrinkite hosto tapatybę, įrašą ir derybas

Pradėkite kliente nuo įrašo, kurį jau turite. Paskelbtas piršto atspaudas, palygintas su patikimu šaltiniu, ir known_hosts įrašas, kuris vis dar sutampa, duoda vienintelį įrodymą, kuris svarbus prieš prasidedant autentifikavimui.

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

Serverio pusėje išspausdinkite piršto atspaudus, kuriuos ketinate paskelbti, o ne nusikopijuokite juos iš atminties. Platinti juos už kanalo ribų yra visa esmė; piršto atspaudas, įklijuotas iš to paties pokalbių kanalo kaip ir hosto vardas, įrodo tik tai, kad abu atėjo iš tos pačios vietos.

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

Suderėti algoritmai kyla iš abiejų pusių sankirtos. Jei kliento konfigūracija prisega pasenusį raktų mainą, kad pasiektų seną įrenginį, tas pasirinkimas galioja kiekvienam hostui, su kuriuo ji kalba, todėl apribokite jį tuo hostu, o ne visuotinai.

Perskaitykite metodus, kuriuos serveris iš tikrųjų priima

Žinojimas, kokius autentifikavimo metodus serveris leidžia, pasako, kam slaptažodis apskritai skirtas. Hostas, priimantis tik viešuosius raktus, neturi slaptažodžių mainų, kuriuos reikėtų saugoti, o hostas, vis dar priimantis slaptažodžius, nusipelno sąmoningo sprendimo, o ne paveldėto numatytojo nustatymo.

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

Naudotojo perkėlimas prie autentifikavimo raktu pašalina to naudotojo slaptažodį iš tų mainų. Tai nepadaro sugadintos darbo stoties saugios ir nepadaro nepatikimos nuotolinės sesijos nekenksmingos. Tai skirtingos rizikos su skirtingomis priemonėmis. Nuspręskite ir dėl agento persiuntimo. Agento persiuntimas į nepatikimą hostą suteikia tam hostui galimybę naudoti jūsų raktus, kol sesija trunka, ir tai didesnis pavojus nei slaptažodžio klausimas, nuo kurio viskas prasidėjo.

Su hosto rakto įspėjimu elkitės kaip su incidento žingsniu

Kai klientas įspėja, kad hosto identifikacija pasikeitė, sustokite ir patikrinkite kanalu, kuris neina tuo pačiu tinklo keliu. Palyginkite piršto atspaudą su serverio konsole arba su operatoriumi, kuris jį perstatė. Ištrinti seną įrašą, kad įspėjimas nutiltų, yra vienintelis veiksmas, kurio turėtumėte atsisakyti. Jis išmeta įrodymą ir paverčia galimą perėmimą įprastu prisijungimu.

Jei hostas buvo teisėtai perstatytas, pašalinkite pasenusį įrašą tik po to, kai patvirtinamas naujas piršto atspaudas, tada prisijunkite iš naujo ir dar kartą patikrinkite derybas. Užregistruokite pakeitimą su data ir priežastimi, nes kitas žmogus pamatys tą patį įspėjimą ir turi žinoti, kad tai išspręsta.

Ko šis vadovas neapima

VPN operatorius, stebintis srautą, nėra tas pats kaip programinė įranga su vietinėmis teisėmis jūsų kompiuteryje. Galinio taško pažeidimas, priešiškas naršyklės plėtinys ar klaviatūros registratorius yra žemiau visko, dėl ko SSH gali derėtis, ir joks tunelis to nepakeis. Jei darbo stotis įtartina, vadovaukitės incidento procedūra, o ne tikrinkite slaptumo jungdamiesi iš naujo per kitą išėjimą. Prisijungimas iš naujo įrodo, kad tinklo kelias pasikeitė, ir nieko apie galinį tašką.

Baikite įprastu atveju: patvirtintas hostas, apsaugotas transportas, sąmoningai pasirinktas autentifikavimo metodas ir joks nereikalingas persiuntimas. Šis derinys yra atsakymas į pavadinime pateiktą klausimą, ir tai keturi sprendimai, o ne vienas.