sshd_configの `ServerAliveInterval`および` ClientAliveInterval`のオプションは正確に何をしますか？
私は この質問 を見つけましたが、受け入れられた応答で言及されている2つの変数ServerAliveIntervalとClientAliveIntervalの設定がよくわかりません。ローカルサーバーがタイムアウトした場合、この値をゼロに設定する必要がありますか？その後、タイムアウトすることはありませんか？代わりに300秒か何かに設定する必要がありますか？
私の質問は、ラップトップをサスペンドしてからサスペンド解除すると、接続の一部がタイムアウトしてWrite failed: Broken pipeとそうでないものもあります。壊れたパイプで失敗しないようにローカルsshdを正しく構成するにはどうすればよいですか？
ServerAliveInterval ：（接続を維持するために）clientがサーバーにnullパケットを送信するまで待機する秒数。
ClientAliveInterval ：（接続を維持するために）serverがクライアントにnullパケットを送信するまで待機する秒数。
値を0（デフォルト）に設定すると、これらの機能が無効になるため、アイドル状態が長すぎると接続が切断される可能性があります。
ServerAliveIntervalは、接続を維持するための最も一般的な戦略のようです。壊れたパイプの問題を防ぐために、.ssh/configファイルで使用するssh構成を次に示します。
Host myhostshortcut
HostName myhost.com
User barthelemy
ServerAliveInterval 60
ServerAliveCountMax 10
上記の設定は次のように機能します。
- クライアントは60秒間（ServerAliveInterval時間）アイドル状態で待機し、 "no-op null packet"をサーバーに送信して応答を待ちます。応答がない場合、10（ServerAliveCountMax）回（600秒）まで上記のプロセスを試行し続けます。それでもサーバーが応答しない場合、クライアントはssh接続を切断します。
サーバー側のClientAliveCountMaxも役立つ場合があります。これは、クライアントが切断される前に応答しない状態を維持できる時間の制限です。 3つのClientAliveIntervalと同様に、デフォルト値は3です。
これは sshd_configマニュアル （man sshd_config）で説明されています：
ClientAliveIntervalタイムアウト間隔を秒単位で設定します。その後、クライアントからデータが受信されない場合、sshdは暗号化されたチャネルを介してメッセージを送信し、クライアントからの応答を要求します。 デフォルトは0で、これらのメッセージがクライアントに送信されないことを示します。このオプションは、プロトコルバージョン2にのみ適用されます。
ClientAliveCountMaxデフォルト値は3です。
ClientAliveInterval（下記参照）が15に設定され、ClientAliveCountMaxがデフォルトのままになっている場合、約45秒後に無応答のSSHクライアントが切断されます。このオプションは、プロトコルバージョン2にのみ適用されます。
クライアントオプションについては、man ssh_configの説明を参照してください。
ServerAliveIntervalタイムアウト間隔を秒単位で設定します。その後、サーバーからデータが受信されない場合、
sshは暗号化されたチャネルを介してメッセージを送信し、サーバーからの応答を要求します。 デフォルトは0で、これらのメッセージがサーバーに送信されないことを示します。このオプションは、プロトコルバージョン2にのみ適用されます。
ServerAliveCountMaxデフォルト値は3です。たとえば、
ServerAliveIntervalが15に設定され、ServerAliveCountMaxがデフォルトのままになっている場合、サーバーが応答しなくなると、約sshが切断されます。 45秒。このオプションは、プロトコルバージョン2にのみ適用されます。
上記に基づいて、0は無効であることを意味します。したがって、これらの値はBroken pipeエラーを回避するのに十分な高さに設定する必要があります。
Barthelemyからの回答はすばらしいですが、問題の根本原因にはなりません。マシンをサスペンドし、コンピューターを起動したときにSSHセッションが存続するようにします。
そのような接続を存続させるsshのそのような構成はありません。 SSHはTCPを使用します。最初に、3方向のハンドシェイクが必要であり、アイドル時間後も存続します。シャットダウン/休止状態にすると、すべてのTCP=接続がFINで閉じられます。これを克服する方法はありません。
汚い回避策の場合は、VPSまたは画面付きの別のオンラインボックスを使用して接続を維持できます。セキュリティ上の理由から、私のアドバイスはそれをしないでください。
一端が受信したパケットへのACKの送信を停止すると、SSH接続（TCPである）が生き続けることは保証できないため、私は個人的に http://www.harding.motd.ca/autossh/ を使用します=一時停止を解除するとすぐに、すべてのSSH接続を再起動します。
GNU画面はサーバー側で使用されるため、再接続すると以前の場所に戻ります。
追加のポートでリッスンして、接続がまだ生きているかどうかを継続的に確認できますが、個人的には、無効にしてSSH自体のServerAliveInterval/ServerAliveCountMaxに依存するだけで十分機能することがわかります。
別のオプションは http://mosh.mit.edu/ で、UDPを使用し、接続の長期的な欠如からシームレスに回復します。
SSH接続に関係なくコマンドを実行する場合は、Nohupを使用してコマンドを実行することもできます。
例えば.
$ Nohup tar -xzf some_huge.tar.gz &
&は必要ないと思いますが、プロセスをバックグラウンドで実行して他のことを実行できるので便利です。
しばらく時間がかかるプロセスには常にNohupを使用しているため、何らかの理由で停電（ホストではなくリモートの場所で）やネットワークの停止などの理由で接続が失われた場合でも、最初からやり直す必要はありません。
長時間実行中のセッションを画面内に配置します詳細については、screen -hを参照してください
そうすれば、sshを使用してマシンに再接続し、screenセッションに再接続できます