Cuando utiliza un túnel SSH, en lo que respecta al servidor de destino, su cliente es el servidor SSH, no el cliente real que se conecta al túnel SSH.
Por ejemplo, si tiene un cliente SSH ejecutándose en 10.1.1.1 , conectándose a un servidor SSH en 10.2.2.2 y estableciendo un túnel a 10.3.3.3 , cuando un cliente (posiblemente desde 10.4.4.4 o en cualquier otro lugar) se conecte al túnel en el final de 10.1.1.1 , obtiene acceso a 10.3.3.3 como si viniera de 10.2.2.2. , no 10.1.1.1 o 10.4.4.4 .
Esto permite que dichas conexiones omitan las reglas del firewall con respecto al servidor de destino que habría permitido las conexiones desde la máquina que ejecuta el servidor SSH, pero no más.
Esto suele ser un problema si el servidor SSH es una puerta de enlace entre dos redes, con una dirección IP pública y una dirección IP privada, por ejemplo. Una regla de firewall que solo permitiría el acceso a ciertos servicios dentro de la LAN interna no detectaría las conexiones de ese servidor SSH (a menos que se haya creado un caso especial para esa máquina).
Las conexiones remotas pueden venir de mucho más lejos. En el lado del cliente SSH, algunos clientes SSH pueden vincular su socket de escucha a una dirección IP específica (por ejemplo, localhost ), al menos para evitar conexiones desde máquinas remotas desde ese extremo. Sin embargo, confía en que el cliente use estas configuraciones correctamente.
Si a sus usuarios se les permite hacer este tipo de conexiones, o si las reglas de firewall (y las relacionadas) que usa en su red manejan la dirección IP del servidor SSH específicamente para tener esto en cuenta, puede estar bien. Dicho esto, es posible que aún desee comprobar dónde están establecidos los túneles, de lo contrario, podría tener problemas con otros servidores de terceros.
Si no necesita nada de esto, sería mejor desactivar esta función.