SSH inverso para un solo dispositivo: ¿escucha de loopback o VPN enrutada?

Tu dispositivo está detrás del NAT de un operador, puede abrir conexiones salientes y ejecuta un servidor SSH al que nadie puede llegar. La petición que llega suele formularse como "dale una VPN", que es una respuesta entre varias. Antes de aceptarla, decide si necesitas un único puerto TCP administrativo o una ruta enrutada hacia una subred completa, porque son proyectos distintos con exposición distinta.

Un túnel inverso responde bien a la versión estrecha. El dispositivo marca hacia tu concentrador, le pide que escuche en un puerto de loopback y reenvía ese puerto de vuelta a su propio servicio SSH. Después, los administradores llegan al oyente a través del concentrador, no a través de internet público.

Tres condiciones que deciden la elección

Anótalas antes de cualquier configuración. Son la frontera entre una entrada de gestión acotada y una extensión de red, y mezclarlas es cómo un túnel de cinco líneas se convierte en una red plana sin dueño.

La tercera fila es la que la gente discute. Un túnel al puerto SSH de un dispositivo no pone a sus vecinos en tu red, y no debe hacerse que parezca que lo hace mediante una cadena de reenvíos adicionales. Si el requisito es realmente la LAN, dilo y diseña esa en su lugar.

Lado del concentrador: una cuenta de retransmisión acotada

Da a cada dispositivo su propia cuenta de retransmisión con autenticación de clave pública y sin sesión interactiva. Match bloque acotado a esa cuenta mantiene el permiso pequeño, y la clave privada se queda en el dispositivo donde pertenece.

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 es la línea interesante. Deniega las sesiones de shell y de subsistemas mientras sigue permitiendo el reenvío que el dispositivo necesita, así que una clave robada no puede convertirse en un inicio de sesión interactivo. PermitListen fija la dirección y el puerto del oyente en el lado del concentrador, y GatewayPorts no lo mantiene en loopback en lugar de abrirlo a la red en la que está el concentrador.

Prueba la configuración efectiva antes de recargar, y mantén una segunda sesión abierta mientras lo haces. Match bloque que se aplica accidentalmente a todos, o una errata en el nombre de una opción, es la forma clásica de quedarte fuera de la máquina que estás endureciendo. Vuelca la configuración en ejecución y vuelve a leer las opciones en lugar de confiar en el archivo que acabas de escribir. Ten en cuenta que el soporte de opciones difiere entre compilaciones, así que una línea aceptada por un servidor más nuevo puede ser simplemente ignorada por uno más antiguo.

Lado del dispositivo: reenvío que falla ruidosamente

El dispositivo abre la conexión y solicita el oyente. Las dos direcciones del argumento -R significan cosas distintas, y leerlas de izquierda a derecha es la forma más rápida de recordar cuál es cuál.

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

El par izquierdo es donde el concentrador debe escuchar. El par derecho es a lo que el dispositivo se conecta cuando llega una petición, resuelto desde el propio lado del dispositivo. Intercambiarlos produce un túnel que sube limpiamente y reenvía al lugar equivocado, lo cual es peor que un fallo.

ExitOnForwardFailure=yes hace que el comando salga cuando el oyente solicitado no puede establecerse, así que un bucle de reinicio te dice la verdad en lugar de dejar una sesión a medio funcionar. No dice nada sobre si el servicio SSH local está sano más adelante, así que combínalo con un gestor de procesos y una prueba de conexión real de vez en cuando.

Nunca sustituyas la dirección de escucha de loopback por un comodín para ahorrarte un salto extra. Ese único cambio es la diferencia entre una ruta de gestión y un puerto alcanzable públicamente, y suele ocurrir durante la depuración y luego se queda. Si un colega no puede llegar al puerto a través del concentrador, arregla la configuración del salto en lugar de ampliar el bind. El loopback es todo el argumento de seguridad de este diseño.

Acceso de administrador a través del concentrador

Un administrador con una cuenta normal en el concentrador puede saltar a través de él hasta el puerto reenviado. La cuenta de retransmisión no se usa para esto, que es justo el punto de mantenerlas separadas.

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

Verifica la clave de host del dispositivo bajo el alias que elegiste, porque esa clave identifica el dispositivo al final de la cadena y el túnel solo es transporte. El inicio de sesión de extremo a extremo sigue autenticando ambos extremos; un túnel que termina en un concentrador compartido no lo convierte por sí solo en una ruta de confianza.

Hazte cargo del ciclo de vida

Ejecuta el comando del dispositivo bajo un gestor de procesos con exactamente una instancia activa y una política de reinicio que hayas elegido a propósito. Las opciones de keepalive detectan un par muerto; no resucitan un proceso que salió.

Después escribe el procedimiento de retirada. Cada dispositivo tiene su propio oyente y su propia clave, así que desmantelarlo significa revocar esa cuenta y eliminar esa clave, no rotar un secreto compartido por toda la flota.

Por último, recuerda qué te aporta el loopback. Limita la exposición de red y no hace nada por otros usuarios locales en un concentrador compartido, así que la política de acceso del propio concentrador sigue teniendo que ser correcta. Referencia de sshd_config documenta cada una de las opciones usadas arriba, y vale la pena leer las secciones de reenvío completas antes de ampliar cualquiera de ellas.