SSH remot sobre una VPN: què no fa el túnel

Una VPN dona a un servidor SSH un camí privat i elimina la necessitat d'un oient públic al port 22. No autentica l'amfitrió, no autoritza l'usuari ni decideix quins comptes poden iniciar sessió. Això continua sent feina d'SSH. Si una VPN és la manera correcta d'arribar al servidor depèn de tres condicions, i el túnel només és una de les respostes possibles.

Què canvia el túnel i què decideix encara SSH

El túnel canvia l'abastabilitat: quines adreces es poden assolir i des d'on. No canvia què passa després que arribi la connexió TCP, on el servidor presenta una clau d'amfitrió i demana la identitat de l'usuari.

Manteniu les dues capes separades al cap i a la documentació. Un inici de sessió VPN demostra qui pot usar la xarxa. No diu res sobre quins comptes existeixen a l'objectiu, i no és permís per iniciar sessió a cada màquina abastable.

Els modes de fallada també són separats, i això és el que fa útil la separació durant un incident.

Tres condicions que decideixen el model d'accés

Primer, el servidor ha de ser abastable per persones fora de la vostra xarxa? Si no, un camí privat més un bastió o una malla és el disseny més petit. Segon, la població de clients pot executar realment el client VPN, inclosos els que són en dispositius gestionats amb restriccions?

Tercer, necessiteu control per servei o control per usuari? Una VPN atorga abast de xarxa; SSH atorga accés al compte. Si el requisit és que un contractista arribi a un amfitrió i a res més, això és un requisit d'autorització i el túnel sol no el pot expressar.

Responeu aquestes tres i el model es tria a si mateix. Salteu-les i acabareu exposant SSH públicament per evitar el desplegament del client.

Confirmeu el camí privat abans de culpar SSH

Connecteu la VPN aprovada i useu el nom o l'adreça privada documentada de l'objectiu. Després comproveu la ruta seleccionada, el permís de la passarel·la i el camí de tornada al client. Un nom que es resol correctament no és prova que l'adreça prengui el túnel previst, perquè els prefixos locals i remots superposats poden enviar la petició a un altre lloc completament. Aquesta distinció val la pena d'escriure-la al runbook.

Si la connexió no arriba mai, confirmeu que el servidor escolta a la interfície que espereu i que el seu tallafoc d'amfitrió permet l'origen que realment veu. Un NAT de passarel·la pot reescriure aquest origen, així que una llista d'autoritzacions escrita per a l'adreça del túnel del client pot no coincidir mai.

Aquesta discrepància és la fallada SSH autoprovocada més habitual sobre una VPN.

Llegiu l'etapa de fallada, no l'error combinat

Tres etapes produeixen tres missatges diferents, i només un d'ells tracta de credencials.

Useu l'error exacte i el registre propi del servidor en lloc de restablir les credencials de VPN i SSH alhora. Restablir les dues és com un diagnòstic de cinc minuts es converteix en un incident d'identitat de dos dies.

La sortida detallada mostra a quina etapa heu arribat:

ssh -vv [email protected]

Manteniu intactes les claus d'amfitrió i l'autorització

Valideu la clau d'amfitrió mitjançant el procés de confiança previst, sobretot després de substituir un servidor. Un avís inesperat de clau canviada és l'únic missatge que no heu de descartar només perquè la VPN s'ha connectat, perquè un túnel privat no fa que la destinació sigui la màquina que penseu. Comproveu l'empremta contra una font en què confieu independentment de la connexió.

Al costat del servidor, confirmeu que el compte està autoritzat i que el mètode d'autenticació que heu configurat és el que s'ofereix. Una clau present però ignorada sol ser un problema de permisos o de configuració, no de xarxa.

Limiteu l'accés als serveis a les identitats necessàries i manteniu un camí de recuperació autoritzat per als canvis de xarxa.