Wie ziet je SSH-wachtwoord nu echt op een onbetrouwbare VPN?

Stuur een SSH-sessie over een VPN die je niet zelf beheert, en het wachtwoord blijft nog steeds van de SSH-server, niet van het netwerk ertussen. Als het transport naar een geverifieerde host goed beschermd is, krijgt een passieve waarnemer op dat pad het wachtwoord niet in leesbare vorm. Maar verander één voorwaarde, en het antwoord verandert: een niet-geverifieerde host, een verzwakte cijferlijst of een gecompromitteerd werkstation geven allemaal andere uitkomsten. Voer de controles hieronder in volgorde uit en behandel elke controle als een stopvoorwaarde.

Noem de ontvanger voordat je iets typt

Het wachtwoordveld reist binnen een authenticatiebericht, en dat bericht reist binnen het versleutelde transport. Vertrouwelijkheid is een eigenschap van het transport, wat betekent dat het afhangt van het onderhandeld hebben van bescherming en van het onderhandeld hebben met de host die je bedoelde. Precies die tweede helft slaan mensen over. Een verbinding die naar een bedrieger is versleuteld, is tegelijk vertrouwelijk en nutteloos. De VPN-login bewijst niets over de SSH-host, en de reputatie van de provider vervangt de sleutelcontrole niet.

Houd de twee richtingen apart in je hoofd. De hostsleutel beantwoordt welke server je hebt bereikt. Wachtwoord- of sleutelauthenticatie beantwoordt welke gebruiker de server accepteert. Het verbeteren van het tweede herstelt nooit het eerste.

Controleer de hostidentiteit, de vermelding en de onderhandeling

Begin op de client met de vermelding die je al hebt. Een gepubliceerde vingerafdruk vergeleken met een vertrouwde bron, en een known_hosts-vermelding die nog steeds klopt, geven je het enige bewijs dat ertoe doet voordat de authenticatie begint.

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

Print aan de serverkant de vingerafdrukken die je wilt publiceren in plaats van ze uit je geheugen te kopiëren. Ze buiten het kanaal verspreiden is juist het punt; een vingerafdruk die uit hetzelfde chatkanaal is geplakt als de hostnaam bewijst alleen dat beide van dezelfde plek komen.

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

De onderhandelde algoritmen komen uit de doorsnede van beide kanten. Als een clientconfiguratie een verouderde sleuteluitwisseling vastzet om een oud apparaat te bereiken, geldt die keuze voor elke host waarmee hij praat, dus beperk hem tot die host in plaats van globaal.

Lees de methoden die de server werkelijk accepteert

Weten welke authenticatiemethoden een server toestaat, vertelt je waar het wachtwoord eigenlijk voor dient. Een host die alleen openbare sleutels accepteert, heeft geen wachtwoorduitwisseling te beschermen, en een host die nog steeds wachtwoorden accepteert verdient een bewuste beslissing in plaats van een geërfde standaardwaarde.

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

Een gebruiker overzetten naar sleutelauthenticatie haalt het wachtwoord van die gebruiker uit die uitwisseling. Het maakt een gecompromitteerd werkstation niet veilig, en het maakt een onbetrouwbare externe sessie niet onschadelijk. Dat zijn verschillende risico’s met verschillende maatregelen. Beslis ook over agent-doorgifte. Een agent doorgeven aan een onbetrouwbare host geeft die host de mogelijkheid je sleutels te gebruiken zolang de sessie duurt, en dat is een grotere blootstelling dan de wachtwoordvraag waarmee het begon.

Behandel een host-sleutelwaarschuwing als een incidentstap

Wanneer de client waarschuwt dat de hostidentificatie is veranderd, stop dan en verifieer via een kanaal dat niet hetzelfde netwerkpad volgt. Vergelijk de vingerafdruk met de serverconsole of met de operator die hem opnieuw heeft opgebouwd. De oude vermelding verwijderen om de waarschuwing te dempen is de enige actie die je moet weigeren. Het gooit het bewijs weg en verandert een mogelijke onderschepping in een gewone login.

Als de host legitiem opnieuw is opgebouwd, verwijder de verouderde vermelding pas nadat de nieuwe vingerafdruk is bevestigd, verbind dan opnieuw en controleer de onderhandeling nog eens. Leg de wijziging vast met datum en reden, want de volgende persoon ziet dezelfde waarschuwing en moet weten dat het is opgelost.

Wat deze handleiding niet dekt

Een VPN-operator die verkeer gadeslaat is niet hetzelfde als software met lokale rechten op je machine. Compromis van het endpoint, een vijandige browserextensie of een toetsenbordlogger zitten onder alles wat SSH kan onderhandelen, en geen enkele tunnel verandert dat. Als het werkstation verdacht is, volg het incidentproces in plaats van geheimhouding te testen door opnieuw te verbinden via een andere uitgang. Opnieuw verbinden bewijst dat het netwerkpad is veranderd en niets over het endpoint.

Sluit af met het gewone geval: geverifieerde host, beschermd transport, de authenticatiemethode die je bewust koos, en geen doorgifte die je niet nodig had. Die combinatie is het antwoord op de vraag in de titel, en het zijn vier beslissingen in plaats van één.