Vem ser egentligen ditt SSH-lösenord på ett ej betrott VPN?

Dirigera en SSH-session över ett VPN som du inte själv driftar, och lösenordet tillhör fortfarande SSH-servern, inte nätet däremellan. Om transporten till en verifierad värd är ordentligt skyddad, får en passiv observatör på den vägen inte lösenordet i läsbar form. Men ändra ett villkor, och svaret ändras: en overifierad värd, en försvagad chifferlista eller en komprometterad arbetsstation ger alla olika utfall. Kör kontrollerna nedan i ordning och behandla var och en som ett stoppvillkor.

Namnge mottagaren innan du skriver något

Lösenordsfältet färdas inuti ett autentiseringsmeddelande, och det meddelandet färdas inuti den krypterade transporten. Konfidentialitet är en egenskap hos transporten, vilket betyder att den beror på att skydd har förhandlats och på att det har förhandlats med den värd du avsåg. Det är just den andra halvan folk hoppar över. En anslutning som är krypterad till en bedragare är konfidentiell och värdelös på samma gång. VPN-inloggningen bevisar ingenting om SSH-värden, och leverantörens rykte ersätter inte nyckelkontrollen.

Håll de två riktningarna åtskilda i huvudet. Värdens nyckel svarar på vilken server du nådde. Lösenords- eller nyckelautentisering svarar på vilken användare servern accepterar. Att förbättra det andra reparerar aldrig det första.

Kontrollera värdens identitet, posten och förhandlingen

Börja på klienten med den post du redan har. Ett publicerat fingeravtryck jämfört med en betrodd källa, och en known_hosts-post som fortfarande stämmer, ger dig det enda bevis som spelar roll innan autentiseringen börjar.

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

Skriv på serversidan ut de fingeravtryck du tänker publicera i stället för att kopiera dem från minnet. Att distribuera dem utanför kanalen är hela poängen; ett fingeravtryck inklistrat från samma chattkanal som värdnamnet bevisar bara att båda kom från samma ställe.

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

De förhandlade algoritmerna kommer från snittet av båda sidor. Om en klientkonfiguration låser en föråldrad nyckelutväxling för att nå en gammal enhet, gäller det valet för varje värd den talar med, så begränsa det till den värden i stället för globalt.

Läs de metoder som servern faktiskt accepterar

Att veta vilka autentiseringsmetoder en server tillåter berättar vad lösenordet över huvud taget är till för. En värd som bara accepterar publika nycklar har ingen lösenordsutväxling att skydda, och en värd som fortfarande accepterar lösenord förtjänar ett medvetet beslut i stället för ett ärvt standardvärde.

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

Att flytta en användare till nyckelautentisering tar bort den användarens lösenord från den utväxlingen. Det gör inte en komprometterad arbetsstation säker, och det gör inte en ej betrodd fjärrsession ofarlig. Det är olika risker med olika kontroller. Bestäm också om agentvidarebefordran. Att vidarebefordra en agent till en ej betrodd värd ger den värden möjlighet att använda dina nycklar så länge sessionen varar, och det är en större exponering än lösenordsfrågan som allt började med.

Behandla en varning om värdnyckeln som ett incidentsteg

När klienten varnar för att värdens identifiering har ändrats, stanna och verifiera via en kanal som inte går genom samma nätverksväg. Jämför fingeravtrycket med serverkonsolen eller med operatören som byggde upp den igen. Att radera den gamla posten för att tysta varningen är den enda åtgärd du bör vägra. Den kastar bort beviset och förvandlar ett möjligt avlyssnande till en vanlig inloggning.

Om värden byggdes upp igen på ett legitimt sätt, ta bort den föråldrade posten först efter att det nya fingeravtrycket har bekräftats, anslut sedan igen och kontrollera förhandlingen på nytt. Registrera ändringen med datum och skäl, eftersom nästa person kommer att se samma varning och behöver veta att den är löst.

Vad den här handboken inte täcker

En VPN-operatör som övervakar trafik är inte samma sak som programvara med lokala privilegier på din maskin. Kompromettering av slutpunkten, ett fientligt webbläsartillägg eller en tangentbordsloggare ligger under allt som SSH kan förhandla om, och ingen tunnel ändrar det. Om arbetsstationen är misstänkt, följ incidentprocessen i stället för att testa hemlighållandet genom att ansluta igen via en annan utgång. Att ansluta igen bevisar att nätverksvägen ändrades och ingenting om slutpunkten.

Avsluta med det vanliga fallet: verifierad värd, skyddad transport, den autentiseringsmetod du valde medvetet och ingen vidarebefordran som du inte behövde. Den kombinationen är svaret på frågan i titeln, och det är fyra beslut i stället för ett.