SSH op afstand via een VPN: wat de tunnel niet doet

Een VPN geeft een SSH-server een privépad en haalt de noodzaak weg van een openbare listener op poort 22. De host wordt er niet door geauthenticeerd, de gebruiker niet geautoriseerd en er wordt niet bepaald welke accounts mogen inloggen. Dat blijft het werk van SSH. Of een VPN de juiste manier is om de server te bereiken, hangt van drie voorwaarden af, en de tunnel is slechts één van de mogelijke antwoorden.

Wat de tunnel verandert en wat SSH nog steeds beslist

De tunnel verandert de bereikbaarheid: welke adressen bereikbaar zijn en van waaruit. Wat er gebeurt nadat de TCP-verbinding tot stand is gekomen, verandert niet: daar toont de server een hostsleutel en vraagt om een gebruikersidentiteit.

Houd de twee lagen gescheiden in je hoofd en in je documentatie. Een VPN-login bewijst wie het netwerk mag gebruiken. Hij zegt niets over welke accounts op het doelsysteem bestaan, en het is geen toestemming om op elke bereikbare machine in te loggen.

De faalwijzen zijn ook gescheiden, en dat is precies wat de scheiding tijdens een incident bruikbaar maakt.

Drie voorwaarden die het toegangsmodel bepalen

Ten eerste: moet de server bereikbaar zijn voor mensen buiten je netwerk? Zo niet, dan is een privépad plus een bastion of een mesh het kleinere ontwerp. Ten tweede: kan de clientpopulatie de VPN-client daadwerkelijk draaien, ook de gebruikers op beheerde apparaten met beperkingen?

Ten derde: heb je sturing per dienst of per gebruiker nodig? Een VPN verleent netwerkbereik; SSH verleent toegang tot accounts. Als de eis is dat een contractor één host bereikt en niets anders, dan is dat een autorisatie-eis en kan de tunnel die alleen niet uitdrukken.

Beantwoord die drie en het model kiest zichzelf. Sla ze over en je eindigt met SSH openbaar blootgesteld om de uitrol van de client te vermijden.

Bevestig het privépad voordat je SSH de schuld geeft

Verbind met de goedgekeurde VPN en gebruik de gedocumenteerde privénaam of het privéadres van het doel. Controleer daarna de geselecteerde route, de toestemming van de gateway en het retourpad naar de client. Een naam die correct resolveert, is geen bewijs dat het adres de bedoelde tunnel neemt, want overlappende lokale en externe prefixen kunnen het verzoek ergens anders naartoe sturen. Dat onderscheid is het waard om in het runbook te schrijven.

Als de verbinding nooit tot stand komt, controleer dan of de server luistert op de interface die je verwacht en of de hostfirewall de bron toelaat die hij werkelijk ziet. Een NAT op de gateway kan die bron herschrijven, dus een allowlist die voor het tunneladres van de client is geschreven, komt mogelijk nooit overeen.

Die mismatch is de meest voorkomende zelfveroorzaakte SSH-fout over een VPN.

Lees de faalfase, niet de gecombineerde fout

Drie fasen produceren drie verschillende meldingen, en slechts één ervan gaat over inloggegevens.

Gebruik de exacte fout en het log van de server zelf, in plaats van zowel de VPN- als de SSH-referenties samen te resetten. Beide resetten is hoe een diagnose van vijf minuten een identiteitsincident van twee dagen wordt.

Uitgebreide uitvoer laat zien welke fase je hebt bereikt:

ssh -vv [email protected]

Houd hostsleutels en autorisatie intact

Valideer de hostsleutel via het bedoelde vertrouwensproces, zeker na een vervanging van de server. Een onverwachte waarschuwing over een gewijzigde sleutel is juist de melding die je niet mag negeren alleen omdat de VPN verbonden is, want een privétunnel maakt van de bestemming niet de machine die je denkt dat het is. Controleer de vingerafdruk tegen een bron die je onafhankelijk van de verbinding vertrouwt.

Controleer aan de serverkant of het account geautoriseerd is en of de authenticatiemethode die je hebt geconfigureerd degene is die wordt aangeboden. Een sleutel die aanwezig is maar genegeerd wordt, is meestal een rechten- of configuratieprobleem en geen netwerkprobleem.

Beperk diensttoegang tot de vereiste identiteiten en houd een geautoriseerd herstelpad achter de hand voor netwerkwijzigingen.