SSH invers per a un sol dispositiu: oient de loopback o VPN amb encaminament?

El vostre dispositiu és darrere d'un NAT d'operador, pot obrir connexions sortints i executa un servidor SSH al qual ningú no pot arribar. La petició que arriba se sol formular com "poseu-li una VPN", que és una resposta entre diverses. Abans d'acceptar-la, decidiu si necessiteu un sol port TCP administratiu o un camí encaminat cap a una subxarxa sencera, perquè són projectes diferents amb exposició diferent.

Un túnel invers respon bé a la versió estreta. El dispositiu marca cap al vostre concentrador, li demana que escolti en un port de loopback i reenvia aquest port cap al seu propi servei SSH. Després els administradors arriben a l'oient a través del concentrador, no a través d'internet públic.

Tres condicions que decanten l'elecció

Anoteu-les abans de qualsevol configuració. Són la frontera entre una entrada de gestió acotada i una extensió de xarxa, i barrejar-les és com un túnel de cinc línies es converteix en una xarxa plana sense amo.

La tercera fila és la que la gent discuteix. Un túnel al port SSH d'un dispositiu no posa els seus veïns a la vostra xarxa, i no se l'ha de fer semblar que ho fa mitjançant una cadena de reenviaments addicionals. Si el requisit és realment la LAN, digueu-ho i dissenyeu-la en lloc d'això.

Costat del concentrador: un compte de relé acotat

Doneu a cada dispositiu el seu propi compte de relé amb autenticació de clau pública i sense sessió interactiva. Match bloc acotat a aquest compte manté el permís petit, i la clau privada es queda al dispositiu on pertoca.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 és la línia interessant. Denega les sessions d'intèrpret i de subsistemes mentre encara permet el reenviament que el dispositiu necessita, així que una clau robada no es pot convertir en un inici de sessió interactiu. PermitListen fixa l'adreça i el port de l'oient al costat del concentrador, i GatewayPorts no el manté al loopback en lloc d'obrir-lo a la xarxa on viu el concentrador.

Proveu la configuració efectiva abans de recarregar, i manteniu una segona sessió oberta mentre ho feu. Match bloc que s'aplica accidentalment a tothom, o una errata en el nom d'una opció, és la manera clàssica de quedar-se fora de la màquina que esteu endurint. Aboqueu la configuració en execució i torneu a llegir les opcions en lloc de confiar en el fitxer que acabeu d'escriure. Tingueu en compte que el suport d'opcions difereix entre versions, així que una línia acceptada per un servidor més nou pot ser simplement ignorada per un de més antic.

Costat del dispositiu: reenviament que falla sorollosament

El dispositiu obre la connexió i demana l'oient. Les dues adreces de l'argument -R signifiquen coses diferents, i llegir-les d'esquerra a dreta és la manera més ràpida de recordar quina és quina.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

La parella esquerra és on el concentrador ha d'escoltar. La parella dreta és a què es connecta el dispositiu quan arriba una petició, resolt des del costat del propi dispositiu. Intercanviar-les produeix un túnel que puja net i reenvia al lloc equivocat, cosa que és pitjor que un fracàs.

ExitOnForwardFailure=yes fa que l'ordre surti quan l'oient sol·licitat no es pot establir, així que un bucle de reinici us diu la veritat en lloc de deixar una sessió mig funcional. No diu res sobre si el servei SSH local està sa més endavant, així que combineu-lo amb un gestor de processos i una prova de connexió real de tant en tant.

No substituïu mai l'adreça d'escolta de loopback per un comodí per estalviar-vos un salt extra. Aquest canvi únic és la diferència entre un camí de gestió i un port abastable públicament, i normalment passa durant la depuració i després es queda. Si un col·lega no pot arribar al port a través del concentrador, arregleu la configuració del salt en lloc d'ampliar el bind. El loopback és tot l'argument de seguretat d'aquest disseny.

Accés d'administrador a través del concentrador

Un administrador amb un compte corrent al concentrador pot saltar-hi fins al port reenviat. El compte de relé no s'utilitza per a això, i aquest és el punt de mantenir-los separats.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

Verifiqueu la clau d'amfitrió del dispositiu sota l'àlies que heu triat, perquè aquesta clau identifica el dispositiu al final de la cadena i el túnel només és transport. L'inici de sessió d'extrem a extrem encara autentica tots dos extrems; un túnel que acaba en un concentrador compartit no el converteix per si sol en un camí de confiança.

Feu-vos càrrec del cicle de vida

Executeu l'ordre del dispositiu sota un gestor de processos amb exactament una instància activa i una política de reinici que hàgiu triat deliberadament. Les opcions de keepalive detecten un parell mort; no ressusciten un procés que ha sortit.

Després escriviu el procediment de retirada. Cada dispositiu té el seu propi oient i la seva pròpia clau, així que desmantellar vol dir revocar aquest compte i eliminar aquesta clau, no rotar un secret compartit per tota la flota.

Finalment, recordeu què us aporta el loopback. Limita l'exposició de xarxa i no fa res pels altres usuaris locals d'un concentrador compartit, així que la política d'accés del propi concentrador encara ha de ser correcta. Referència d'sshd_config documenta cadascuna de les opcions utilitzades més amunt, i val la pena llegir les seccions de reenviament senceres abans d'ampliar-ne cap.