Una cuenta de proxy SSH puede funcionar sin shell

La configuración tentadora es AllowTcpForwarding no. Lamentablemente, también desactiva el reenvío que necesita un proxy SOCKS SSH local. El reenvío dinámico no es un atajo para eludir la política del servidor.

Para una cuenta dedicada, OpenSSH separa varias capacidades. Un fragmento de política puede permitir el reenvío local y a la vez impedir las sesiones de shell y de subsistema:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

El manual del servidor describe MaxSessions 0 como una opción que impide las sesiones de shell, inicio de sesión y subsistema mientras permite el reenvío. Intégrela en una cuenta autenticada existente; no es una configuración de seguridad SSH completa.

Solo reenvío no es solo SOCKS

Un reenvío local fijo y una solicitud SOCKS pueden acabar pidiendo al servidor el mismo tipo de conexión de destino. Permitir el reenvío local no garantiza que un cliente haya usado una interfaz SOCKS concreta. No describa la cuenta como impositora de un uso solo SOCKS.

PermitOpen puede restringir pares de host y puerto de destino cuando una lista concreta encaja con el requisito. No es una prohibición general consciente de la resolución de nombres sobre cada red privada. Las restricciones de direcciones más amplias pueden necesitar una política de red de host adecuada.

La configuración de la cuenta, la clave y el servidor incluido pueden restringir aún más el reenvío. Una prohibición total de reenvío en otro lugar puede eliminar una capacidad que este fragmento parece permitir.

Utilice el procedimiento habitual de administración del servidor con una ruta de recuperación y luego evalúe por separado las capacidades permitidas y denegadas. El resultado previsto son permisos de reenvío explícitos, no un inicio de sesión interactivo dejado disponible por accidente ni un proxy desactivado por su propia restricción.