Wie werden Ports auf dem SSH-Server freigegeben, wenn ein umgekehrter SSH-Tunnel die Verbindung abrupt / unsauber trennt?

Wir haben eine Hardware, die wir bei unseren Kunden installieren, die sich mit unserem SSH-Server verbindet und einen Reverse-SSH-Tunnel aufbaut, damit wir zu Überwachungszwecken auf mehrere Client-Systeme zugreifen können.

Alles funktioniert einwandfrei, bis die SSH-Sitzung nicht mehr sauber getrennt wird.

In diesem Fall bleiben die vom Reverse-Tunnel verwendeten Ports auf unserem SSH-Server im LISTENING-Modus hängen. Wenn unsere Remote-Hardware schließlich versucht, eine automatische Wiederverbindung herzustellen und die Tunnel wiederherzustellen, schlägt der Fehler fehl

Warnung: Die Weiterleitung des Remote-Ports für den Listen-Port XXXX ist fehlgeschlagen

Ich habe getestet, ob es ein Problem mit unserem SSH-Server oder -Client gab, indem ich versucht habe, eine saubere Verbindung zu trennen und natürlich die Ports freizugeben. Wenn ich einen Verbindungsfehler simuliere (z. B. den Ethernet-Port der Client-Hardware trennen), haben wir das gleiche Problem, das ich oben beschrieben habe.

Wie kann man mit dieser Situation umgehen? Beachten Sie, dass es sich um umgekehrte Tunnel handelt, sodass alle Vorgänge auf dem SSH-Server ausgeführt werden müssen. Im Idealfall muss der SSH-Server sofort erkennen, dass die SSH-Sitzung, die die Tunnel hostet, inaktiv ist, und die von ihm verwendeten Ports freigeben. Ich denke, die Lösung könnte darin bestehen, den betroffenen SSH-Prozess zu beenden, aber ich muss vorsichtig sein, da wir mehrere Clients haben, die sich mit demselben SSH-Server verbinden, und ich möchte sie nicht offline schalten.

Da SSHD so ausgereift ist, habe ich sicher eine Art eingebautes Feature, um damit umzugehen, aber ich kann es einfach nicht herausfinden.

Bitte raten Sie mir, damit ich nicht mehr Windows-Boxen verwalten muss ...

Zu Ihrer Information: Ich verwende dies auf einer Debian-basierten Distribution.

Sie müssen ClientAliveIntervalin Ihrem verwenden 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.