SSH フォークで接続が終了します。

私はこれが実際にあなたの問題を引き起こすとは思わない-f。私はあなたの命令に間違ったことがないと思います。これは正しい状況でうまく機能します。

ただし、SSHクライアントとSSHサーバー間のパスにステートフルミドルウェアがある場合、そのミドルウェアの状態が失われると、SSH接続は終了または停止されます。これは、パスにNATまたはファイアウォールがある場合は特に注意する必要があることを意味します。

Keepalive メッセージは、タイムアウトにより接続が中断されるのを防ぎます。他の理由で（たとえば、ミドルウェアの再起動など）接続が終了するのを防ぐことはできませんが、この場合、Keepaliveは接続が中断されずにすぐに終了するかどうかを検出し、接続がすぐに終了するようにすることができます。

クライアントは-o ServerAliveInterval=299同様のものを使用してキープアライブを送信し、接続が失われた場合はsshコマンドがすぐに終了するかどうかを確認できます。これを繰り返しシェルスクリプトでラップすると、以前の接続が終了するたびに新しいSSH接続を開くことができます（ただし、この場合はSSHコマンドではなくスクリプトフォークが必要です）。

-Lポート転送をアクティブに保つには、ServerAliveIntervalsshコマンドを再生成するだけで十分です。しかし、-R間違っている可能性がある別のことがあります。

サーバーのポートですでにリッスンしているエントリがある場合、ポート転送は-R設定されませんが、sshコマンドは引き続き実行されます。したがって、この場合、sshコマンドの再生成を目的としたループは役に立ちません。

この問題に対する解決策は、これを-o ExitOnForwardFailure=yessshコマンドに渡すことです。明らかに、対応するフラグの組み合わせを使用してループ内でsshを起動すると、同じ占有ポートに連続して複数回バインドを試みることができます。したがって、連続的な試みの間にしばらく休憩することは非常に良いです。 sshコマンドが終了するたびに、スクリプトは数秒待機状態になってから再試行する必要があります。

上記のすべてのタスクを実行する複数のスクリプトが存在しない場合は驚きます。

これまでに述べた内容が必要なすべてのものを扱うわけではありません。

接続が停止し、クライアントがそれを認識してsshコマンドを再起動しようとすると、サーバーがまだ認識されていない可能性があるため、サーバー側のポートがまだ占有されている可能性があります。誰かが愚かな方法でファイアウォールを構成した場合、クライアントのスクリプトはまだブロックされているポートに繰り返しバインドしようとするため、問題は無限に続く可能性があります。

誰もがファイアウォールの設定を変更するよう説得するのがうまくいかない可能性が高いので、設定を調整して問題を回避することをお勧めします。sshd_config設定を調整するClientAliveIntervalと、サーバーはクライアントに接続の保持メッセージを送受信できなかった場合に接続を閉じるために使用できます。返信する

上記のすべてを組み合わせると、ポート転送を常にアクティブに保つのに十分です（クライアントとサーバー間にネットワーク接続があると仮定）。