Comment libérer des ports sur le serveur SSH lorsqu'un tunnel ssh inverse se déconnecte brusquement / impur?

Nous avons un certain matériel que nous installons chez nos clients, ce matériel se connecte à notre serveur ssh et établit un tunnel ssh inverse afin que nous puissions accéder à plusieurs systèmes clients à des fins de surveillance.

Tout fonctionne bien jusqu'à ce qu'il y ait une déconnexion impure de la session SSH.

Lorsque cela se produit, sur notre serveur SSH, les ports utilisés par le tunnel inverse restent bloqués en mode ECOUTE et lorsque notre matériel distant essaie finalement de se reconnecter automatiquement et de rétablir ses tunnels, il échoue avec l'erreur

Avertissement: le transfert de port distant a échoué pour le port d'écoute XXXX

J'ai testé s'il y avait un problème avec notre serveur ou client SSH en essayant une déconnexion propre et un cours qui libère très bien les ports. Lorsque je simule un échec de connexion (déconnectez le port Ethernet du matériel client par exemple), nous avons le même problème que celui décrit ci-dessus.

Quelle est la bonne façon de gérer cette situation? Gardez à l'esprit que ce sont des tunnels inversés, donc tout ce qui se passe doit être fait sur le serveur SSH. Idéalement, j'ai besoin du serveur ssh pour réaliser instantanément que la session SSH hébergeant les tunnels est en panne et libérer les ports qu'il utilisait. Je suppose que la solution pourrait impliquer de tuer le processus SSH concerné, mais je dois faire attention à cela car nous avons plusieurs clients se connectant au même serveur ssh et je ne voudrais pas les mettre hors ligne.

Étant si mature, je suis sûr que SSHD a une sorte de fonctionnalité intégrée pour gérer cela, mais je ne peux pas le comprendre.

S'il vous plaît avisez-moi donc je n'ai pas à revenir à l'administration des boîtes Windows ...

Pour info: je lance ceci sur une distribution basée sur Debian.

Vous devez utiliser ClientAliveIntervaldans votre sshd_config.

ClientAliveInterval 15

Réf: 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.