Можно ли установить ClientAliveInterval со стороны клиента?

Нет, управлять этими настройками со стороны клиента невозможно. Они контролируют, как часто сервер отправляет сообщения проверки активности и сколько нужно ждать, прежде чем отключиться. Это общие настройки сервера -, которые применяются ко всем подключениям. Разрешение клиентам устанавливать их, даже для каждого соединения -, будет иметь последствия для безопасности, поскольку это может позволить злоумышленникам потреблять чрезмерные ресурсы сервера.

Если вы хотите установить эти настройки, вам нужно будет сделать это в файле /etc/sshd/sshd_configсервера. Обратите внимание, что установка их таким образом, чтобы сброшенные соединения быстро завершались, не должна быть проблемой, поскольку, как правило, эти соединения в конечном итоге все равно будут сброшены.

Если вы можете использовать отдельное соединение только для переадресации порта (с ), т. е., возможно, с -N, рассмотрите этот обходной путь:

while echo; do sleep 1; done | ssh user@server 'exec bash -c "while read -t 5; do :; done"'

(Включить переадресацию портов (с )самостоятельно ).

Когда новые строки из echoперестанут поступать на удаленную сторону, read -t 5в конечном итоге завершится ошибкой, и весь удаленный цикл завершится. Сервер SSH заметит, что его дочерний процесс завершился, он разорвет соединение и освободит порт (s ).

Примечания:

• read -tне является переносимым, команда явно вызывает bashдля его обработки.
• Если интерпретатором команд для user@serverявляется bash, тогда нет необходимости в exec bash; подошва"while read -t 5; do :; done"(вместо'exec bash -c …')будет работать.
• read -t 5довольно просто. Вы можете разработать код, реализующий концепцииIntervalи CountMax.

Я протестировал этот подход на своем ноутбуке.с фактической переадресацией удаленного порта(-R)и beepвместо :, чтобы слышать от сервера. Когда я отключил Wi -Fi, писк прекратился. Когда я быстро снова подключился к Wi -Fi, звуковой сигнал повторился и продолжился. Но когда я снова подключился на несколько секунд позже, локальная команда вышла, потому что узнала, что SSH-сервер разорвал соединение, как и было задумано. Важные дела:

• Были и другие подключения SSH к тому же серверу, управляемые *AliveIntervalи *AliveCountMax, и они сохранились. Это означает, что мое специальное соединение закончилось без помощи этих опций. Если бы я ждал достаточно долго с выключенным Wi -Fi, то почти все соединения разрывались бы из-за опций, включая локальную половину специального соединения. Исключением будет удаленная половина; он все равно бы уже давно исчез, потому что bashуже вышел.
• Я смог снова подключиться сразу же , так и не получил remote port forwarding failed for listen port. Поэтому я думаю, что мой подход может быть правильным решением вашей проблемы.