SSH отключает переадресацию портов удаленно, вместо того, чтобы убивать процесс на сервере

ТЛ; др

Используйте эти sshd параметры на сервере (в sshd_config файл):

ClientAliveCountMax 3
ClientAliveInterval 15

История на стороне клиента

Как я могу удаленно отменить переадресацию портов с устройства, которое его запросило, вместо того, чтобы убивать процесс на сервере?

Простой ответ: просто прекратить ssh на клиенте. Даже если вы принудительно уничтожите его, сервер должен быть уведомлен о том, что соединение разорвано (потому что ядро ​​выполняет эту работу).

... если уведомление когда-либо попадет на сервер, то есть. Я думаю, что это проблема. Сеть на вашем устройстве как-то падает до того ssh завершен, и нет никакого способа уведомить сервер, что это конкретное соединение SSH больше не.

Может быть, вы можете изменить дизайн на стороне клиента, чтобы обеспечить ssh завершается до того, как что-либо будет сделано с сетевым подключением. Я не знаю деталей вашей клиентской системы, поэтому я не скажу вам точно, что вы можете сделать и как. Свободные примеры: systemd единицы и их зависимости, если применимо; обертка над reboot и / или shutdown,

Серверная история

Я предполагаю, что сервер SSH является стандартным sshd, Конфиг по умолчанию (sshd_config) указывает

TCPKeepAlive yes

От man 5 sshd_config:

TCPKeepAlive

Указывает, должна ли система отправлять сообщения поддержки активности TCP другой стороне. Если они отправлены, смерть соединения или сбой одной из машин будут замечены должным образом. Однако это означает, что соединения прекратят свое существование, если маршрут временно не работает, и некоторые люди считают это раздражающим. С другой стороны, если сообщения поддержки активности TCP не отправляются, сеансы могут бесконечно зависать на сервере, оставляя "призрачных" пользователей и потребляя ресурсы сервера.

По умолчанию yes (для отправки сообщений поддержки активности TCP), и сервер заметит, если сеть выйдет из строя или произойдет сбой хоста клиента. Это позволяет избежать бесконечно зависающих сессий.

Этот механизм не специфичен для SSH. Объяснение:

В Linux параметры поддержки активности TCP:

tcp_keepalive_intvl
tcp_keepalive_probes
tcp_keepalive_time

Их значения по умолчанию:

tcp_keepalive_time = 7200 (в секундах)
tcp_keepalive_intvl = 75 (в секундах)
tcp_keepalive_probes = 9 (количество зондов)

Это означает, что процесс keepalive ожидает в течение двух часов (7200 секунд) активности сокета, прежде чем отправлять первый запрос keepalive, а затем отправлять его каждые 75 секунд. Если нет ACK Ответ получен девять раз подряд, соединение помечено как разорванное.

( Источник).

Это объясняет, почему вам "нужно подождать около 1-2 часов, чтобы порт снова был свободен".

Примеры того, как вы можете изменить эти значения (если у вас есть разрешения):

• временно

  echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
  

  или же

  sysctl -w net.ipv4.tcp_keepalive_time=300
  

• навсегда, редактируя /etc/sysctl.conf файл, добавьте:

  net.ipv4.tcp_keepalive_time=300
  

  затем вызвать sudo sysctl -p применить изменения.

Но это общесистемные настройки. В целом, любое изменение повлияет более чем на sshd, Вот почему лучше использовать SSH-специфичное решение. Опять из man 5 sshd_config:

ClientAliveCountMax

Устанавливает количество живых сообщений клиента (см. Ниже), которые могут быть отправлены без sshd(8) получать любые сообщения обратно от клиента. Если этот порог достигнут, пока клиент отправляет живые сообщения, sshd отключит клиента, завершив сеанс. Важно отметить, что использование живых сообщений клиента сильно отличается от TCPKeepAlive, […] Механизм работы клиента полезен, когда клиент или сервер зависят от того, когда соединение стало неактивным.

Значением по умолчанию является 3, Если ClientAliveInterval (см. ниже) установлен на 15, а также ClientAliveCountMax по умолчанию, не отвечающие клиенты SSH будут отключены примерно через 45 секунд. Эта опция применяется только к версии протокола 2.

ClientAliveInterval

Устанавливает интервал ожидания в секундах, после которого, если данные не были получены от клиента, sshd(8) отправит сообщение через зашифрованный канал для запроса ответа от клиента. По умолчанию 0, указывая, что эти сообщения не будут отправлены клиенту. Эта опция применяется только к версии протокола 2.

Если только вы можете перенастроить sshd на сервере это, на мой взгляд, самый элегантный способ. Пусть sshd_config содержат строки вроде:

ClientAliveCountMax 3
ClientAliveInterval 15

Заметки:

• -o ServerAliveInterval=60 вы используете похожий вариант для ssh; это позволяет клиенту обнаруживать разрыв соединения. Это не влияет на сервер, хотя.
• вы можете рассмотреть autossh на клиенте.

Вернуться к клиенту

Предположим, вы не можете перенастроить ни сервер, ни клиент. Я знаю, что ты сказал

вместо того, чтобы убивать процесс на сервере

но в этом случае убийство может быть лучшим вариантом. Как sshd вилки обслуживают определенные соединения, достаточно просто убить нужный процесс, не влияя на остальные. Чтобы инициировать убийство с клиента, вы должны изменить способ вызова ssh, Вы сказали:

каждые несколько минут:

ssh -f …

Вместо этого вы можете запустить скрипт, похожий на следующий, только один раз (например, через @reboot в хронтаб). Он пытается убить сохраненный PID (из sshd на сервере) сначала установите туннель и сохраните его sshd PID. Если туннель не может быть установлен или в конце концов завершен, сценарий некоторое время спит и зацикливается.

#!/bin/sh
port=12345
address=user@server
while :; do
  ssh $address '[ -f ~/.tunnel.pid ] && kill `cat ~/.tunnel.pid` && rm ~/.tunnel.pid'
  ssh -o ExitOnForwardFailure=yes -R ${port}:localhost:22 $address 'echo $PPID > ~/.tunnel.pid; exec sleep infinity'
  sleep 60
done

Заметки:

• Это быстрый и грязный сценарий, подтверждение концепции; мобильность не была моим приоритетом.
• Для ясности я опустил некоторые опции, которые вы изначально использовали.
• Если вы запустите скрипт дважды, два экземпляра будут убивать туннели друг друга снова и снова.