18

У нас есть некоторое оборудование, которое мы устанавливаем в местах расположения наших клиентов, которое подключается к нашему ssh-серверу и устанавливает обратный ssh-туннель, чтобы мы могли получить доступ к нескольким клиентским системам для целей мониторинга.

Все работает нормально, пока не произойдет нечистое отключение сеанса SSH.

Когда это происходит, на нашем SSH-сервере порты, которые использовались обратным туннелем, остаются в режиме LISTENING, и когда наше удаленное оборудование в конечном итоге пытается автоматически переподключиться и заново установить свои туннели, происходит сбой с ошибкой

Предупреждение: переадресация удаленного порта на прослушиваемый порт не удалась

Я проверил, была ли проблема с нашим SSH-сервером или клиентом, попробовав чистое разъединение и курс, который прекрасно освобождает порты. Когда я имитирую сбой соединения (например, отключаю Ethernet-порт клиентского оборудования), у нас возникает та же проблема, которую я описал выше.

Как правильно обращаться с этой ситуацией? Имейте в виду, что это обратные туннели, поэтому все, что происходит, должно быть выполнено на сервере SSH. В идеале мне нужен сервер ssh, чтобы мгновенно понять, что сеанс SSH, на котором размещены туннели, не работает, и освободить порты, которые он использовал. Я предполагаю, что решение может включать в себя уничтожение соответствующего процесса SSH, но мне нужно быть осторожным с этим, потому что у нас есть несколько клиентов, подключающихся к одному и тому же серверу ssh, и я бы не хотел отключать их в автономном режиме.

Будучи настолько зрелым, я уверен, что SSHD имеет какую-то встроенную функцию, чтобы справиться с этим, но я просто не могу понять это.

Посоветуйте, пожалуйста, чтобы я не возвращался к администрированию окон Windows ...

К вашему сведению: я использую этот дистрибутив на основе Debian.

1 ответ1

16

Вы должны использовать ClientAliveInterval в вашем sshd_config .

ClientAliveInterval 15

Ссылка: 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.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .