Kdo vlastně vidí vaše SSH heslo na nedůvěryhodné VPN?

Veďte SSH relaci přes VPN, kterou nespravujete, a heslo pořád patří SSH serveru, ne síti mezi nimi. Pokud je přenos k ověřenému hostiteli řádně chráněný, pasivní pozorovatel na této cestě nedostane heslo v čitelné podobě. Změňte ale jednu podmínku a odpověď se změní: neověřený hostitel, oslabený seznam šifer nebo kompromitovaná pracovní stanice dávají různé výsledky. Proveďte níže uvedené kontroly v pořadí a každou berte jako podmínku zastavení.

Pojmenujte příjemce, než něco napíšete

Pole hesla putuje uvnitř autentizační zprávy a ta zpráva putuje uvnitř šifrovaného přenosu. Důvěrnost je vlastnost přenosu, což znamená, že závisí na tom, zda bylo vyjednáno chránění a zda bylo vyjednáno s hostitelem, který jste zamýšleli. Právě druhou polovinu lidé přeskakují. Spojení šifrované k podvodníkovi je současně důvěrné i zbytečné. Přihlášení k VPN nedokazuje nic o SSH hostiteli a pověst poskytovatele není náhradou kontroly klíče.

Držte oba směry oddělené v hlavě. Klíč hostitele odpovídá na to, na který server jste se dostali. Ověřování heslem nebo klíčem odpovídá na to, kterého uživatele server přijme. Vylepšení druhého nikdy nespraví první.

Zkontrolujte totožnost hostitele, záznam a vyjednávání

Začněte na klientovi se záznamem, který už máte. Zveřejněný otisk porovnaný s důvěryhodným zdrojem a záznam v known_hosts, který stále sedí, vám dají jediný důkaz, na kterém před začátkem ověřování záleží.

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

Na straně serveru vypište otisky, které hodláte zveřejnit, místo abyste je kopírovali z paměti. Rozšiřovat je mimo kanál je právě ten smysl; otisk vložený ze stejného chatovacího kanálu jako název hostitele dokazuje jen to, že oba pocházejí ze stejného místa.

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

Vyjednané algoritmy vycházejí z průniku obou stran. Pokud konfigurace klienta připíná zastaralou výměnu klíčů, aby dosáhla na staré zařízení, platí tato volba pro každého hostitele, se kterým mluví, takže ji omezíte na tohoto hostitele, ne globálně.

Přečtěte si metody, které server skutečně přijímá

Vědět, které metody ověřování server povoluje, vám řekne, k čemu vlastně heslo je. Hostitel, který přijímá jen veřejné klíče, nemá žádnou výměnu hesel k ochraně, a hostitel, který stále přijímá hesla, si zaslouží vědomé rozhodnutí, ne zděděnou výchozí hodnotu.

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

Přepnutí uživatele na ověřování klíčem odstraní heslo toho uživatele z této výměny. Neudělá kompromitovanou pracovní stanici bezpečnou a neudělá nedůvěryhodnou vzdálenou relaci neškodnou. To jsou různá rizika s různými opatřeními. Rozhodněte také o předávání agenta. Předání agenta nedůvěryhodnému hostiteli dá tomuto hostiteli možnost používat vaše klíče po dobu relace, což je větší expozice než otázka hesla, kterou to začalo.

Berte varování o klíči hostitele jako krok incidentu

Když klient varuje, že se identifikace hostitele změnila, zastavte se a ověřte to kanálem, který neprochází stejnou síťovou cestou. Porovnejte otisk s konzolí serveru nebo s operátorem, který ho přestavěl. Smazání starého záznamu, aby varování utichlo, je jediná akce, kterou je třeba odmítnout. Zahodí důkazy a možné odposlouchávání promění v běžné přihlášení.

Pokud byl hostitel legitimně přestavěn, odstraňte zastaralý záznam až po potvrzení nového otisku, potom se znovu připojte a znovu zkontrolujte vyjednávání. Zapište změnu s datem a důvodem, protože příští člověk uvidí stejné varování a potřebuje vědět, že je vyřešeno.

Co tato příručka nepokrývá

Operátor VPN, který sleduje provoz, není totéž jako software s místními oprávněními na vašem stroji. Kompromitace koncového bodu, nepřátelské rozšíření prohlížeče nebo keylogger leží pod vším, co SSH může vyjednat, a žádný tunel to nezmění. Pokud je pracovní stanice podezřelá, postupujte podle procesu pro incidenty, místo abyste zkoušeli utajení opětovným připojením přes jiný výstup. Opětovné připojení dokazuje, že se síťová cesta změnila, a nic o koncovém bodu.

Skončete běžným případem: ověřený hostitel, chráněný přenos, metoda ověřování, kterou jste zvolili záměrně, a žádné předávání, které jste nepotřebovali. Tahle kombinace je odpovědí na otázku v názvu a jsou to čtyři rozhodnutí, ne jedno.