Ekstern SSH over en VPN: hva tunnelen ikke gjør

En VPN gir en SSH-tjener en privat vei og fjerner behovet for en offentlig lytter på port 22. Den autentiserer ikke verten, autoriserer ikke brukeren og avgjør ikke hvilke kontoer som får logge inn. Det er fortsatt SSH sin jobb. Om en VPN er den riktige måten å nå tjeneren på, avhenger av tre betingelser, og tunnelen er bare ett av de mulige svarene.

Hva tunnelen endrer, og hva SSH fortsatt avgjør

Tunnelen endrer tilgjengelighet: hvilke adresser som kan nås, og hvorfra. Den endrer ikke det som skjer etter at TCP-forbindelsen lander, der tjeneren presenterer en vertsnøkkel og ber om en brukeridentitet.

Hold de to lagene atskilt i hodet og i dokumentasjonen din. En VPN-innlogging beviser hvem som får bruke nettverket. Den sier ingenting om hvilke kontoer som finnes på målet, og det er ikke tillatelse til å logge på enhver tilgjengelig maskin.

Feilmodusene er også atskilte, og det er det som gjør atskillelsen nyttig under en hendelse.

Tre betingelser som avgjør tilgangsmodellen

For det første, må tjeneren være tilgjengelig for folk utenfor nettverket ditt? Hvis ikke, er en privat vei pluss en bastion eller et mesh det mindre designet. For det andre, kan klientpopulasjonen faktisk kjøre VPN-klienten, inkludert de på administrerte enheter med begrensninger?

For det tredje, trenger du kontroll per tjeneste eller kontroll per bruker? En VPN gir nettverkstilgang; SSH gir kontotilgang. Hvis kravet er at en entreprenør når én vert og ingenting annet, er det et autorisasjonskrav, og tunnelen alene kan ikke uttrykke det.

Svar på de tre, og modellen velger seg selv. Hopp over dem, og du ender med å eksponere SSH offentlig for å unngå klientutrullingen.

Bekreft den private veien før du klandrer SSH

Koble til den godkjente VPN-en og bruk målets dokumenterte private navn eller adresse. Sjekk deretter den valgte ruten, gatewayens tillatelse og returveien til klienten. Et navn som løses riktig er ikke bevis for at adressen tar den tiltenkte tunnelen, fordi overlappende lokale og eksterne prefikser kan sende forespørselen et helt annet sted. Den forskjellen er verdt å skrive inn i runbooken.

Hvis forbindelsen aldri lander, bekreft at tjeneren lytter på grensesnittet du forventer og at vertsbrannmuren tillater kilden den faktisk ser. En gateway-NAT kan skrive om den kilden, så en tillatelsesliste skrevet for klientens tunneladresse passer kanskje aldri.

Det avviket er den vanligste selvpåførte SSH-feilen over en VPN.

Les feilsteget, ikke den kombinerte feilen

Tre stadier produserer tre forskjellige meldinger, og bare én av dem handler om legitimasjon.

Bruk den nøyaktige feilen og tjenerens egen logg i stedet for å tilbakestille både VPN- og SSH-legitimasjon samtidig. Å tilbakestille begge er måten en fem minutters diagnose blir en to dagers identitetshendelse.

Den detaljerte utskriften viser hvilket stadium du nådde:

ssh -vv [email protected]

Hold vertsnøkler og autorisasjon intakte

Valider vertsnøkkelen gjennom den tiltenkte betrodde prosessen, spesielt etter en tjenerutskifting. En uventet advarsel om endret nøkkel er den ene meldingen du ikke må avvise bare fordi VPN-en ble tilkoblet, fordi en privat tunnel ikke gjør målet til maskinen du tror. Sjekk fingeravtrykket mot en kilde du stoler på uavhengig av forbindelsen.

På tjenersiden bekrefter du at kontoen er autorisert og at autentiseringsmetoden du konfigurerte er den som tilbys. En nøkkel som er til stede men ignoreres, er vanligvis et tillatelses- eller konfigurasjonsproblem snarere enn et nettverksproblem.

Begrens tjenestetilgangen til de påkrevde identitetene og hold en autorisert gjenopprettingsvei for nettverksendringer.