Fjern-SSH over en VPN: hvad tunnelen ikke gør

En VPN giver en SSH-server en privat vej og fjerner behovet for en offentlig lytter på port 22. Den godkender ikke værten, autoriserer ikke brugeren og afgør ikke, hvilke konti der må logge ind. Det er stadig SSH's opgave. Om en VPN er den rigtige måde at nå serveren på, afhænger af tre betingelser, og tunnelen er kun et af de mulige svar.

Hvad tunnelen ændrer, og hvad SSH stadig afgør

Tunnelen ændrer tilgængelighed: hvilke adresser der kan nås, og hvorfra. Den ændrer ikke, hvad der sker, efter TCP-forbindelsen lander, hvor serveren fremviser en værtsnøgle og beder om en brugeridentitet.

Hold de to lag adskilt i hovedet og i din dokumentation. Et VPN-login beviser, hvem der må bruge netværket. Det siger intet om, hvilke konti der findes på målet, og det er ikke tilladelse til at logge ind på enhver tilgængelig maskine.

Fejltilstandene er også adskilte, og det er det, der gør adskillelsen nyttig under en hændelse.

Tre betingelser, der afgør adgangsmodellen

For det første, skal serveren kunne nås af folk uden for dit netværk? Hvis ikke, er en privat vej plus en bastion eller et mesh det mindre design. For det andet, kan klientpopulationen faktisk køre VPN-klienten, inklusive dem på administrerede enheder med begrænsninger?

For det tredje, har du brug for kontrol per tjeneste eller kontrol per bruger? En VPN giver netværksadgang; SSH giver kontoadgang. Hvis kravet er, at en entreprenør når én vært og intet andet, er det et autorisationskrav, og tunnelen alene kan ikke udtrykke det.

Svar på de tre, og modellen vælger sig selv. Spring dem over, og du ender med at eksponere SSH offentligt for at undgå klientudrulningen.

Bekræft den private vej, før du bebrejder SSH

Opret forbindelse til den godkendte VPN, og brug målets dokumenterede private navn eller adresse. Kontroller derefter den valgte rute, gatewayens tilladelse og returvejen til klienten. Et navn, der opløses korrekt, er ikke bevis for, at adressen tager den tilsigtede tunnel, fordi overlappende lokale og fjernpræfikser kan sende anmodningen et helt andet sted hen. Den forskel er værd at skrive ind i runbooken.

Hvis forbindelsen aldrig lander, bekræft, at serveren lytter på det interface, du forventer og at dens værtsfirewall tillader den kilde, den faktisk ser. En gateway-NAT kan omskrive den kilde, så en tilladelsesliste skrevet til klientens tunneladresse måske aldrig matcher.

Den uoverensstemmelse er den mest almindelige selvforskyldte SSH-fejl over en VPN.

Læs fejlstadiet, ikke den kombinerede fejl

Tre stadier giver tre forskellige meddelelser, og kun én af dem handler om legitimationsoplysninger.

Brug den nøjagtige fejl og serverens egen log i stedet for at nulstille både VPN- og SSH-legitimationsoplysninger på én gang. At nulstille begge er måden, hvorpå en fem minutters diagnose bliver en identitetshændelse på to dage.

Det verbose output viser, hvilket stadie du nåede:

ssh -vv [email protected]

Hold værtsnøgler og autorisation intakte

Valider værtsnøglen gennem den tilsigtede betroede proces, især efter en serverudskiftning. En uventet advarsel om ændret nøgle er den ene meddelelse, du ikke må afvise, blot fordi VPN'en blev forbundet, fordi en privat tunnel ikke gør destinationen til den maskine, du tror. Kontroller fingeraftrykket mod en kilde, du stoler på uafhængigt af forbindelsen.

På serversiden skal du bekræfte, at kontoen er autoriseret, og at den godkendelsesmetode, du konfigurerede, er den, der tilbydes. En nøgle, der er til stede, men ignoreres, er normalt et rettigheds- eller konfigurationsproblem snarere end et netværksproblem.

Afgræns tjenesteadgang til de krævede identiteter, og hold en autoriseret gendannelsesvej for netværksændringer.