SSH på avstand over eit VPN: kva tunnelen ikkje gjer

Eit VPN gjev ein SSH-tenar ein privat veg og fjernar trongen for ein offentleg lyttar på port 22. Det autentiserer ikkje verten, autoriserer ikkje brukaren og avgjer ikkje kva kontoar som får logge inn. Det blir framleis SSH sitt arbeid. Om eit VPN er den rette måten å nå tenaren på, kjem an på tre vilkår, og tunnelen er berre eitt av dei moglege svara.

Kva tunnelen endrar, og kva SSH framleis avgjer

Tunnelen endrar nåbarheit: kva adresser som kan nåast, og kvar frå. Han endrar ikkje det som skjer etter at TCP-sambandet er oppe, der tenaren viser ein vertsnøkkel og spør etter ein brukaridentitet.

Hald dei to laga frå kvarandre i hovudet og i dokumentasjonen din. Ei VPN-innlogging provar kven som får bruke nettverket. Ho seier ingenting om kva kontoar som finst på måltenaren, og ho er ikkje løyve til å logge inn på kvar einaste maskin du kan nå.

Feilmåtane er òg skilde, og det er nettopp det som gjer skiljet nyttig under ei hending.

Tre vilkår som avgjer tilgangsmodellen

Fyrst: må tenaren kunne nåast av folk utanfor nettverket ditt? Om ikkje, er ein privat veg pluss ein bastion eller eit mesh det mindre designet. Andre: kan brukargruppa faktisk køyre VPN-klienten, også dei på styrte einingar med avgrensingar?

Tredje: treng du styring per teneste eller per brukar? Eit VPN gjev nettverksrekkevidd; SSH gjev kontotilgang. Om kravet er at ein innleigd konsulent når éin vert og ikkje noko anna, er det eit autorisasjonskrav, og tunnelen åleine kan ikkje uttrykkje det.

Svar på dei tre, så vel modellen seg sjølv. Hoppar du over dei, endar du med å eksponere SSH offentleg for å sleppe klientutrullinga.

Stadfest den private vegen før du gjev SSH skulda

Kopla til det godkjende VPN-et og bruk det dokumenterte private namnet eller den private adressa til målet. Sjekk deretter den valde ruta, løyvet i gatewayen og returvegen til klienten. Eit namn som blir løyst ut rett, er ikkje prov for at adressa tek den tiltenkte tunnelen, for overlappande lokale og eksterne prefiks kan sende førespurnaden ein heilt annan stad. Det skiljet er verdt å skrive inn i runboka.

Om sambandet aldri kjem opp, stadfest at tenaren lyttar på grensesnittet du ventar, og at vertsbrannmuren hans tillèt den kjelda han faktisk ser. Ein NAT i gatewayen kan skrive om den kjelda, så ei tillatingsliste skriven for tunneladressa til klienten kan aldri kome til å stemme.

Det misforholdet er den vanlegaste sjølvpåførte SSH-feilen over eit VPN.

Les feilfasen, ikkje den samla feilen

Tre fasar gjev tre ulike meldingar, og berre éi av dei handlar om innloggingsdetaljar.

Bruk den nøyaktige feilen og loggen til tenaren sjølv, i staden for å nullstille både VPN- og SSH-detaljane samtidig. Å nullstille begge er slik ein fem minutt lang diagnose blir ei identitetshending på to dagar.

Utvida utskrift viser kva fase du nådde:

ssh -vv [email protected]

Hald vertsnøklar og autorisasjon intakte

Valider vertsnøkkelen gjennom den tiltenkte tillitsprosessen, særleg etter at ein tenar er bytt ut. Ei uventa åtvaring om endra nøkkel er nettopp den meldinga du ikkje må avfeie berre fordi VPN-et kopla til, for ein privat tunnel gjer ikkje målet til den maskinen du trur det er. Sjekk fingeravtrykket mot ei kjelde du stolar på uavhengig av sambandet.

På tenarsida: stadfest at kontoen er autorisert, og at autentiseringsmetoden du sette opp, er den som blir tilboden. Ein nøkkel som finst men blir ignorert, er vanlegvis eit rettigheits- eller konfigurasjonsproblem og ikkje eit nettverksproblem.

Avgrens tenestetilgangen til dei identitetane som trengst, og hald ein autorisert attopprettingsveg for nettverksendringar.