Kto naozaj vidí vaše SSH heslo na nedôveryhodnej VPN?
Vykonajte kontroly totožnosti pred zadaním hesla cez VPN a potom rozdeľte identitu servera, overenie používateľa a dôveru ku koncovému bodu na tri rozhodnutia.
Veďte SSH reláciu cez VPN, ktorú sami nespravujete, a heslo stále patrí SSH serveru, nie sieti medzi nimi. Ak je prenos k overenému hostiteľovi riadne chránený, pasívny pozorovateľ na tejto ceste nedostane heslo v čitateľnej podobe. Zmeňte však jednu podmienku a odpoveď sa zmení: neoverený hostiteľ, oslabený zoznam šifier alebo kompromitovaná pracovná stanica dávajú rôzne výsledky. Vykonajte nižšie uvedené kontroly v poradí a každú berte ako podmienku zastavenia.
Pomenujte príjemcu, skôr než čokoľvek napíšete
Pole hesla putuje vnútri autentifikačnej správy a tá správa putuje vnútri šifrovaného prenosu. Dôvernosť je vlastnosť prenosu, čo znamená, že závisí od toho, či bola vyjednaná ochrana a či bola vyjednaná s hostiteľom, ktorého ste zamýšľali. Práve druhú polovicu ľudia preskakujú. Spojenie šifrované k podvodníkovi je súčasne dôverné aj zbytočné. Prihlásenie do VPN nič nedokazuje o SSH hostiteľovi a povesť poskytovateľa nenahrádza kontrolu kľúča.
Držte oba smery oddelene v hlave. Kľúč hostiteľa odpovedá na to, na ktorý server ste sa dostali. Overovanie heslom alebo kľúčom odpovedá na to, ktorého používateľa server prijme. Vylepšenie druhého nikdy neopraví prvé.
Skontrolujte totožnosť hostiteľa, záznam a vyjednávanie
Začnite na klientovi so záznamom, ktorý už máte. Zverejnený odtlačok porovnaný s dôveryhodným zdrojom a záznam v known_hosts, ktorý stále sedí, vám dajú jediný dôkaz, na ktorom pred začiatkom overovania záleží.
ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net
Na strane servera vypíšte odtlačky, ktoré hodláte zverejniť, namiesto toho, aby ste ich kopírovali z pamäte. Ich distribúcia mimo kanála je práve celý zmysel; odtlačok vložený z toho istého chatového kanála ako názov hostiteľa dokazuje len to, že oba pochádzajú z rovnakého miesta.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'
Vyjednané algoritmy vychádzajú z prieniku oboch strán. Ak konfigurácia klienta pripína zastaranú výmenu kľúčov, aby dosiahla staré zariadenie, táto voľba platí pre každého hostiteľa, s ktorým hovorí, preto ju obmedzte na tohto hostiteľa, nie globálne.
Prečítajte si metódy, ktoré server skutočne prijíma
Vedieť, ktoré metódy overovania server povoľuje, vám povie, načo je heslo vôbec určené. Hostiteľ, ktorý prijíma len verejné kľúče, nemá žiadnu výmenu hesiel na ochranu, a hostiteľ, ktorý stále prijíma heslá, si zaslúži vedomé rozhodnutie, nie zdedenú predvolenú hodnotu.
sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'
Prechod používateľa na overovanie kľúčom odstráni heslo tohto používateľa z tej výmeny. Neurobí kompromitovanú pracovnú stanicu bezpečnou a neurobí nedôveryhodnú vzdialenú reláciu neškodnou. To sú rôzne riziká s rôznymi opatreniami. Rozhodnite aj o presmerovaní agenta. Presmerovanie agenta na nedôveryhodného hostiteľa dáva tomuto hostiteľovi možnosť používať vaše kľúče, kým relácia trvá, a to je väčšia expozícia než otázka hesla, ktorou to celé začalo.
Berte varovanie o kľúči hostiteľa ako krok incidentu
Keď klient varuje, že sa identifikácia hostiteľa zmenila, zastavte sa a overte to kanálom, ktorý neprechádza tou istou sieťovou cestou. Porovnajte odtlačok s konzolou servera alebo s operátorom, ktorý ho prestaval. Vymazanie starého záznamu, aby varovanie utíchlo, je jediná akcia, ktorú treba odmietnuť. Zahodí dôkaz a možné odpočúvanie premení na bežné prihlásenie.
Ak bol hostiteľ legitímne prestavaný, odstráňte zastaraný záznam až po potvrdení nového odtlačku, potom sa znova pripojte a znova skontrolujte vyjednávanie. Zapíšte zmenu s dátumom a dôvodom, pretože ďalší človek uvidí to isté varovanie a potrebuje vedieť, že je vyriešené.
Čo táto príručka nepokrýva
Operátor VPN, ktorý sleduje prevádzku, nie je to isté ako softvér s miestnymi oprávneniami na vašom počítači. Kompromitácia koncového bodu, nepriateľské rozšírenie prehliadača alebo keylogger ležia pod všetkým, čo SSH dokáže vyjednať, a žiaden tunel to nezmení. Ak je pracovná stanica podozrivá, postupujte podľa incidentového procesu, namiesto toho, aby ste testovali utajenie opätovným pripojením cez iný výstup. Opätovné pripojenie dokazuje, že sa sieťová cesta zmenila, a nič o koncovom bode.
Skončite bežným prípadom: overený hostiteľ, chránený prenos, metóda overovania, ktorú ste zvolili zámerne, a žiadne presmerovanie, ktoré ste nepotrebovali. Táto kombinácia je odpoveďou na otázku v nadpise a sú to štyri rozhodnutia, nie jedno.