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

Et VPN gir en SSH-server en privat vei og fjerner behovet for en offentlig lytter på port 22. Det autentiserer ikke verten, autoriserer ikke brukeren og avgjør ikke hvilke kontoer som får logge inn. Det er fortsatt SSH sin jobb. Om et VPN er riktig måte å nå serveren på, avhenger av tre vilkår, og tunnelen er bare ett av de mulige svarene.

Hva tunnelen endrer, og hva SSH fortsatt bestemmer

Tunnelen endrer tilgjengeligheten: hvilke adresser som kan nås, og hvorfra. Den endrer ikke det som skjer etter at TCP-forbindelsen er oppe, der serveren viser en vertsnøkkel og ber om en brukeridentitet.

Hold de to lagene fra hverandre 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ålserveren, og den er ikke tillatelse til å logge inn på hver eneste maskin du kan nå.

Feilmodusene er også atskilt, og det er nettopp det som gjør skillet nyttig under en hendelse.

Tre vilkår som avgjør tilgangsmodellen

For det første: må serveren kunne nås av folk utenfor nettverket ditt? Hvis ikke, er en privat vei pluss en bastion eller et mesh det mindre designet. For det andre: kan brukergruppen faktisk kjøre VPN-klienten, også de på styrte enheter med begrensninger?

For det tredje: trenger du styring per tjeneste eller per bruker? Et VPN gir nettverksrekkevidde; SSH gir kontotilgang. Hvis kravet er at en innleid konsulent når én vert og ingenting annet, er det et autorisasjonskrav, og tunnelen alene kan ikke uttrykke det.

Svar på de tre, så velger modellen seg selv. Hopper du over dem, ender du med å eksponere SSH offentlig for å slippe klientutrulleringen.

Bekreft den private veien før du gir SSH skylden

Koble til det godkjente VPN-et og bruk det dokumenterte private navnet eller den private adressen til målet. Sjekk deretter den valgte ruten, tillatelsen i gatewayen og returveien til klienten. Et navn som løses ut riktig, er ikke bevis for at adressen tar den tiltenkte tunnelen, for overlappende lokale og eksterne prefikser kan sende forespørselen et helt annet sted. Den forskjellen er verdt å skrive inn i runboken.

Hvis forbindelsen aldri kommer opp, bekreft at serveren lytter på grensesnittet du forventer, og at vertsbrannmuren tillater kilden den faktisk ser. En NAT i gatewayen kan skrive om den kilden, så en tillatelsesliste skrevet for klientens tunneladresse kan aldri komme til å stemme.

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

Les feilfasen, ikke den samlede feilen

Tre faser gir tre ulike meldinger, og bare én av dem handler om påloggingsdetaljer.

Bruk den nøyaktige feilen og loggen til serveren selv, i stedet for å nullstille både VPN- og SSH-detaljene samtidig. Å nullstille begge er hvordan en fem minutters diagnose blir en identitetshendelse på to dager.

Utvidet utskrift viser hvilken fase du nådde:

ssh -vv [email protected]

Hold vertsnøkler og autorisasjon intakte

Valider vertsnøkkelen gjennom den tiltenkte tillitsprosessen, særlig etter at en server er byttet ut. En uventet advarsel om endret nøkkel er nettopp den meldingen du ikke må avvise bare fordi VPN-et koblet til, for en privat tunnel gjør ikke målet til den maskinen du tror det er. Sjekk fingeravtrykket mot en kilde du stoler på uavhengig av forbindelsen.

På serversiden: bekreft at kontoen er autorisert, og at autentiseringsmetoden du satte opp, er den som tilbys. En nøkkel som finnes men ignoreres, er vanligvis et rettighets- eller konfigurasjonsproblem og ikke et nettverksproblem.

Avgrens tjenestetilgangen til identitetene som trengs, og hold en autorisert gjenopprettingsvei for nettverksendringer.