Como liberar portas no servidor SSH quando um túnel ssh reverso é desconectado de forma abrupta / suja?

Temos alguns hardwares que instalamos nos locais de nossos clientes, que se conectam ao nosso servidor ssh e estabelecem um túnel ssh reverso para que possamos obter acesso a vários sistemas clientes para fins de monitoramento.

Tudo funciona bem até que haja uma desconexão imunda da sessão SSH.

Quando isso acontece, em nosso servidor SSH, as portas que foram usadas pelo túnel reverso permanecem paralisadas no modo LISTENING e, quando nosso hardware remoto finalmente tenta se reconectar automaticamente e restabelecer seus túneis, ela falha com o erro

Aviso: falha no encaminhamento de porta remota para a porta de escuta XXXX

Testei se havia um problema com o servidor ou cliente SSH, tentando uma desconexão limpa e o curso que libera as portas corretamente. Quando simulo uma falha de conexão (desconecte a porta Ethernet do hardware do cliente, por exemplo), temos o mesmo problema que descrevi acima.

Qual é a maneira correta de lidar com essa situação? Lembre-se de que esses são túneis invertidos; portanto, o que quer que aconteça, precisa ser feito no servidor SSH. Idealmente, eu preciso do servidor ssh para perceber instantaneamente que a sessão SSH que hospeda os túneis está inoperante e libera as portas que estava usando. Acho que a solução pode envolver a morte do processo SSH em questão, mas preciso ter cuidado com isso, pois temos vários clientes se conectando ao mesmo servidor ssh e não gostaria de expulsá-los offline.

Sendo tão maduro, tenho certeza de que o SSHD tem algum tipo de recurso interno para lidar com isso, mas simplesmente não consigo descobrir.

Por favor, informe para que eu não precise voltar a administrar as caixas do Windows ...

FYI: Estou executando isso em uma distribuição baseada no Debian.

Você tem que usar ClientAliveIntervalno seu 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.