¿Cómo liberar puertos en el servidor SSH cuando un túnel ssh inverso se desconecta de manera abrupta / sucia?

Tenemos un hardware que instalamos en las ubicaciones de nuestros clientes, ese hardware se conecta a nuestro servidor ssh y establece un túnel ssh inverso para que podamos obtener acceso a varios sistemas de clientes con fines de monitoreo.

Todo funciona bien hasta que haya una desconexión impura de la sesión SSH.

Cuando eso sucede, en nuestro servidor SSH los puertos que fueron utilizados por el túnel inverso permanecen atascados en el modo de ESCUCHAR y cuando nuestro hardware remoto finalmente intenta reconectarse automáticamente y restablecer sus túneles, falla con el error

Advertencia: error de reenvío de puerto remoto para el puerto de escucha XXXX

Probé si había un problema con nuestro servidor o cliente SSH al intentar una desconexión limpia y un curso que liberara bien los puertos. Cuando simulo una falla de conexión (desconecte el puerto Ethernet del hardware del cliente, por ejemplo), entonces tenemos el mismo problema que describí anteriormente.

¿Cuál es la forma correcta de manejar esta situación? Tenga en cuenta que estos son túneles invertidos, por lo que pase lo que pase debe hacerse en el servidor SSH. Idealmente, necesito que el servidor ssh se dé cuenta instantáneamente de que la sesión SSH que aloja los túneles está inactiva y libere los puertos que estaba usando. Supongo que la solución podría implicar matar el proceso SSH en cuestión, pero tengo que tener cuidado con eso porque tenemos varios clientes que se conectan al mismo servidor ssh y no me gustaría desconectarlos.

Siendo tan maduro, estoy seguro de que SSHD tiene algún tipo de función incorporada para manejar esto, pero simplemente no puedo entenderlo.

Por favor avise para que no tenga que volver a administrar los cuadros de Windows ...

FYI: estoy ejecutando esto en una distribución basada en Debian.

Tienes que usar ClientAliveIntervalen tu sshd_config.

ClientAliveInterval 15

Ref: 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.