Come rilasciare le porte sul server SSH quando un tunnel SSH inverso si disconnette bruscamente / sporcamente?

Abbiamo un hardware che installiamo presso le sedi dei nostri clienti, che l'hardware si collega al nostro server SSH e stabilisce un tunnel SSH inverso in modo da poter accedere a diversi sistemi client a scopo di monitoraggio.

Tutto funziona bene fino a quando non vi è una disconnessione impura della sessione SSH.

Quando ciò accade, sul nostro server SSH le porte utilizzate dal tunnel inverso rimangono bloccate in modalità ASCOLTO e quando il nostro hardware remoto alla fine tenta di riconnettersi automaticamente e ristabilire i suoi tunnel, fallisce con l'errore

Avviso: il port forwarding remoto non è riuscito per la porta di ascolto XXXX

Ho testato se c'era un problema con il nostro server o client SSH provando una disconnessione pulita e ovviamente il rilascio delle porte. Quando simulo un errore di connessione (ad esempio scollegare la porta Ethernet dell'hardware client), abbiamo lo stesso problema che ho descritto sopra.

Qual è il modo corretto di gestire questa situazione? Tieni presente che questi sono tunnel invertiti, quindi qualsiasi cosa accada deve essere eseguita sul server SSH. Idealmente ho bisogno del server SSH per rendermi conto istantaneamente che la sessione SSH che ospita i tunnel è inattiva e rilasciare le porte che stava usando. Immagino che la soluzione potrebbe comportare l'uccisione del processo SSH interessato, ma devo fare attenzione a quella causa, poiché abbiamo più client che si collegano allo stesso server SSH e non vorrei metterli fuori linea.

Essendo così maturo, sono sicuro che SSHD ha una sorta di funzionalità integrata per gestirlo, ma non riesco proprio a capirlo.

Si prega di avvisare, quindi non devo tornare ad amministrare le finestre di Windows ...

FYI: Sto eseguendo questo su una distribuzione basata su Debian.

Devi usare ClientAliveIntervalnel tuo sshd_config.

ClientAliveInterval 15

Rif: man sshd_config

ClientAliveCountMax
         Sets the number of client alive messages (see below) which may be
         sent without sshd(8) receiving any messages back from the client.
         If this threshold is reached while client alive messages are
         being sent, sshd will disconnect the client, terminating the
         session.  It is important to note that the use of client alive
         messages is very different from TCPKeepAlive (below).  The client
         alive messages are sent through the encrypted channel and
         therefore will not be spoofable.  The TCP keepalive option
         enabled by TCPKeepAlive is spoofable.  The client alive mechanism
         is valuable when the client or server depend on knowing when a
         connection has become inactive.

         The default value is 3.  If ClientAliveInterval (see below) is
         set to 15, and ClientAliveCountMax is left at the default,
         unresponsive SSH clients will be disconnected after approximately
         45 seconds.  This option applies to protocol version 2 only.

 ClientAliveInterval
         Sets a timeout interval in seconds after which if no data has
         been received from the client, sshd(8) will send a message
         through the encrypted channel to request a response from the
         client.  The default is 0, indicating that these messages will
         not be sent to the client.  This option applies to protocol
         version 2 only.