Fjärr-SSH över ett VPN: vad tunneln inte gör

Ett VPN ger en SSH-server en privat väg och tar bort behovet av en offentlig lyssnare på port 22. Det autentiserar inte värden, auktoriserar inte användaren och avgör inte vilka konton som får logga in. Det är fortfarande SSH:s jobb. Om ett VPN är rätt sätt att nå servern beror på tre villkor, och tunneln är bara ett av de möjliga svaren.

Vad tunneln ändrar och vad SSH fortfarande avgör

Tunneln ändrar nåbarheten: vilka adresser som kan nås, och varifrån. Den ändrar inte vad som händer efter att TCP-anslutningen har etablerats, där servern visar en värdnyckel och frågar efter en användaridentitet.

Håll de två lagren åtskilda i huvudet och i dokumentationen. En VPN-inloggning bevisar vem som får använda nätet. Den säger inget om vilka konton som finns på målet och är inte tillstånd att logga in på varje nåbar maskin.

Fellägena är också åtskilda, och det är just därför uppdelningen är användbar under en incident.

Tre villkor som avgör åtkomstmodellen

För det första, måste servern vara nåbar för människor utanför ditt nät? Om inte är en privat väg plus en bastion eller ett mesh den mindre designen. För det andra, kan klientpopulationen faktiskt köra VPN-klienten, inklusive de på hanterade enheter med begränsningar?

För det tredje, behöver du styrning per tjänst eller per användare? Ett VPN ger nätnåbarhet; SSH ger kontotillgång. Om kravet är att en entreprenör når en värd och inget annat, är det ett auktoriseringskrav och tunneln ensam kan inte uttrycka det.

Svara på de tre och modellen väljer sig själv. Hoppa över dem och du slutar med att exponera SSH offentligt för att undvika klientutrullningen.

Bekräfta den privata vägen innan du skyller på SSH

Anslut till det godkända VPN:et och använd målets dokumenterade privata namn eller adress. Kontrollera sedan den valda rutten, gatewayens behörighet och returvägen till klienten. Ett namn som löses ut korrekt är inte bevis för att adressen tar den avsedda tunneln, eftersom överlappande lokala och avlägsna prefix kan skicka begäran någon helt annanstans. Den skillnaden är värd att skriva in i runbooken.

Om anslutningen aldrig kommer upp, bekräfta att servern lyssnar på det gränssnitt du förväntar dig och att dess värdbrandvägg tillåter den källa den faktiskt ser. En NAT i gatewayen kan skriva om den källan, så en tillåtelselista skriven för klientens tunneladress kanske aldrig matchar.

Den missanpassningen är det vanligaste självförvållade SSH-felet över ett VPN.

Läs fasen för felet, inte det sammanslagna felet

Tre faser ger tre olika meddelanden, och bara ett av dem handlar om inloggningsuppgifter.

Använd det exakta felet och serverns egen logg i stället för att återställa både VPN- och SSH-uppgifterna samtidigt. Att återställa båda är hur en femminutersdiagnos blir en identitetsincident på två dagar.

Utförlig utskrift visar vilken fas du nådde:

ssh -vv [email protected]

Håll värdnycklar och auktorisering intakta

Validera värdnyckeln genom den avsedda betrodda processen, särskilt efter ett serverbyte. En oväntad varning om ändrad nyckel är just det meddelande du inte får avvisa bara för att VPN:et anslöt, eftersom en privat tunnel inte gör målet till den maskin du tror att det är. Kontrollera fingeravtrycket mot en källa du litar på oberoende av anslutningen.

På serversidan, bekräfta att kontot är auktoriserat och att den autentiseringsmetod du konfigurerade är den som erbjuds. En nyckel som finns men ignoreras är oftast ett behörighets- eller konfigurationsproblem och inte ett nätverksproblem.

Begränsa tjänstens åtkomst till de identiteter som krävs och håll en auktoriserad återställningsväg för nätändringar.