Quando usi un tunnel SSH, per quanto riguarda il server di destinazione, il suo client è il server SSH, non il vero client che si connette al tunnel SSH.
Ad esempio, se hai un client SSH in esecuzione su 10.1.1.1 , connettendo a un server SSH su 10.2.2.2 e stabilendo un tunnel a 10.3.3.3 , quando un client (possibilmente da 10.4.4.4 o da qualsiasi altra parte) si connette al tunnel sul 10.1.1.1 fine, ottiene l'accesso a 10.3.3.3 come se provenisse da 10.2.2.2. , non 10.1.1.1 o 10.4.4.4 .
Ciò consente a tali connessioni di bypassare le regole del firewall relative al server di destinazione che avrebbe consentito le connessioni dalla macchina che esegue il server SSH, ma non oltre.
Questo è tipicamente un problema se il server SSH è un gateway tra due reti, con indirizzo IP pubblico e un indirizzo IP privato, per esempio. Una regola del firewall che consentirebbe solo l'accesso a determinati servizi all'interno della LAN interna non catturerebbe le connessioni da quel server SSH (a meno che non sia stato creato un caso speciale per quella macchina).
Le connessioni remote potrebbero venire da molto più lontano. Sul lato client SSH, alcuni client SSH possono associare il loro socket di ascolto a uno specifico indirizzo IP (ad esempio localhost ), almeno per impedire connessioni da macchine remote da quella parte. Tuttavia, ci si basa sul client che utilizza queste impostazioni correttamente.
Se i tuoi utenti sono autorizzati a fare questo tipo di connessioni, o se le regole del firewall (e relative) che usi nella tua rete gestiscono l'indirizzo IP del server SSH in modo specifico per tenerne conto, può andare bene. Detto questo, potresti voler controllare anche dove sono stabiliti i tunnel, altrimenti potresti anche guai con altri server di terze parti.
Se non ti serve nulla di tutto questo, disabilitare questa funzione sarebbe meglio.