SSH inverso para un só dispositivo: escoitador de loopback ou VPN encamiñada?

O teu dispositivo está detrás do NAT dun operador, pode abrir conexións saíntes e executa un servidor SSH ao que ninguén pode chegar. A petición que chega adoita formularse como "dálle unha VPN", que é unha resposta entre varias. Antes de aceptala, decide se necesitas un único porto TCP administrativo ou unha ruta encamiñada cara a unha subrede completa, porque son proxectos distintos con exposición distinta.

Un túnel inverso responde ben á versión estreita. O dispositivo marca cara ao teu concentrador, pídelle que escoite nun porto de loopback e reenvía ese porto de volta ao seu propio servizo SSH. Despois, os administradores chegan ao escoitador a través do concentrador, non a través de internet público.

Tres condicións que deciden a elección

Anótaas antes de calquera configuración. Son a fronteira entre unha entrada de xestión acoutada e unha extensión de rede, e mesturalas é como un túnel de cinco liñas se converte nunha rede plana sen dono.

A terceira fila é a que a xente discute. Un túnel ao porto SSH dun dispositivo non pon os seus veciños na túa rede, e non debe facerse que pareza que o fai mediante unha cadea de reenvíos adicionais. Se o requisito é realmente a LAN, dío e deseña esa no seu lugar.

Lado do concentrador: unha conta de retransmisión acoutada

Dálle a cada dispositivo a súa propia conta de retransmisión con autenticación de clave pública e sen sesión interactiva. Match bloque acoutado a esa conta mantén o permiso pequeno, e a clave privada queda no dispositivo onde pertence.

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 é a liña interesante. Denega as sesións de shell e de subsistemas mentres aínda permite o reenvío que o dispositivo necesita, así que unha clave roubada non pode converterse nun inicio de sesión interactivo. PermitListen fixa o enderezo e o porto do escoitador no lado do concentrador, e GatewayPorts no manteno en loopback en lugar de abrirlo á rede na que está o concentrador.

Proba a configuración efectiva antes de recargar, e mantén unha segunda sesión aberta mentres o fas. Match bloque que se aplica accidentalmente a todos, ou unha errata no nome dunha opción, é a forma clásica de quedares fóra da máquina que estás a endurecer. Volca a configuración en execución e volve ler as opcións en lugar de confiar no ficheiro que acabas de escribir. Ten en conta que o soporte de opcións difire entre compilacións, así que unha liña aceptada por un servidor máis novo pode ser simplemente ignorada por un máis antigo.

Lado do dispositivo: reenvío que falla ruidosamente

O dispositivo abre a conexión e solicita o escoitador. Os dous enderezos do argumento -R significan cousas distintas, e lelos de esquerda a dereita é a forma máis rápida de lembrar cal é cal.

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

O par esquerdo é onde o concentrador debe escoitar. O par dereito é aquilo ao que o dispositivo se conecta cando chega unha petición, resolto desde o propio lado do dispositivo. Intercambialos produce un túnel que sobe limpiamente e reenvía ao lugar equivocado, o cal é peor ca un fallo.

ExitOnForwardFailure=yes fai que o comando saia cando o escoitador solicitado non se pode establecer, así que un bucle de reinicio che di a verdade en lugar de deixar unha sesión a medio funcionar. Non di nada sobre se o servizo SSH local está san máis adiante, así que combínao cun xestor de procesos e unha proba de conexión real de cando en vez.

Nunca substitúas o enderezo de escoita de loopback por un comodín para aforrar un salto extra. Ese único cambio é a diferenza entre unha ruta de xestión e un porto alcanzable publicamente, e adoita ocorrer durante a depuración e logo queda. Se un compañeiro non pode chegar ao porto a través do concentrador, arranxa a configuración do salto en lugar de ampliar o bind. O loopback é todo o argumento de seguridade deste deseño.

Acceso de administrador a través do concentrador

Un administrador cunha conta normal no concentrador pode saltar a través del ata o porto reenviado. A conta de retransmisión non se usa para isto, e ese é xustamente o punto de mantelas separadas.

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

Verifica a clave de host do dispositivo baixo o alias que escolliches, porque esa clave identifica o dispositivo ao final da cadea e o túnel só é transporte. O inicio de sesión de extremo a extremo segue autenticando ambos os extremos; un túnel que remata nun concentrador compartido non o converte por si só nunha ruta de confianza.

Fai te cargo do ciclo de vida

Executa o comando do dispositivo baixo un xestor de procesos con exactamente unha instancia activa e unha política de reinicio que escolliches a propósito. As opcións de keepalive detectan un par morto; non resucitan un proceso que saíu.

Despois escribe o procedemento de retirada. Cada dispositivo ten o seu propio escoitador e a súa propia clave, así que desmantelalo significa revogar esa conta e eliminar esa clave, non rotar un segredo compartido por toda a frota.

Por último, lembra que che achega o loopback. Limita a exposición de rede e non fai nada polos outros usuarios locais nun concentrador compartido, así que a política de acceso do propio concentrador segue tendo que ser correcta. Referencia de sshd_config documenta cada unha das opcións usadas arriba, e paga a pena ler as seccións de reenvío completas antes de ampliar calquera delas.