sshタイムアウトがネットワークの場所によって異なるのはなぜですか？
自宅から（Fedora 10を実行している）オフィスサーバーの1つに接続すると、かなり短い期間（5分程度）でセッションがタイムアウトします。クライアント側でTcpKeepAliveを使用しようとしましたが、効果はありません。
私が理解していないことは、会社のLANのオフィスにいる場合、タイムアウトすることなく終日セッションを非アクティブのままにできるため、動作は私の場所に依存しているようです。
これがなぜ起こっているのか、そして私がLAN上にいないときにタイムアウトを防ぐ方法はありますか？それが役立つ場合は、Mac OSXでターミナルクライアントを使用しています。
[〜＃〜] update [〜＃〜]-ServerAliveIntervalを0以外に設定してTcpKeepAlive=noを使用するというDave Dragerの提案がうまくいきました。他のいくつかの回答に関しては、ClientAlive...設定がMac OSX SSHクライアントによって受け入れられません。
この問題については、よく説明されています ここ 。
彼らはお勧めします：
ssh -o TCPKeepAlive=yes
または：
ssh -o TCPKeepAlive=no -o ServerAliveInterval=15
しかし、私は自分の職場で、セッションが切断されるという問題を抱えています。自宅では問題ありません。私のファイアウォール（SonicWall）は、おそらくNATが原因で、TCPKeepAliveを使用している可能性があります。
私のSSHクライアントであるSecureCRTには、幸いなことに「NO-OP」プロトコルのオプションがあります。これは基本的にサーバーに何もしないコマンドを送信すると思います。これを手動で有効にすることで、接続を維持できます。 MacOSXターミナルクライアントが何を持っているかはよくわかりません。コマンドラインで「NO-OP」を実装する方法について writeup があります。
最後に、Wiresharkまたは他のスニファを使用して実際のTCP接続を監視し、何が起こっているかを確認します。これが、たまにまだ切断されている理由を確認する最後の方法です。 。
私はこれを自分のComcast接続で常に入手しています。問題は、SSHクライアントのキープアライブ間隔が、ネットワークパスで構成されたタイムアウトに対して長すぎることです。 Linuxを使用している場合は、ServerAliveIntervalとServerAliveCounterの値をデフォルトよりも低くなるように変更できます。この値は秒単位で設定されます。システム全体の構成ファイルは、（通常）/etc/ssh/ssh_configにあります。これら2つのAND TcpKeepAliveを設定すると、接続を継続するのに役立ちます。
これはおそらく、自宅から接続しているときにファイアウォールを通過するためですTCPセッションが少し後に閉じます。しかし、TcpKeepAliveはこれを回避する必要があります。クライアント側または上でTcpKeepAliveを有効にしましたかサーバ側 ？
Radiusが言うように、一部のステートフルファイアウォールは、一定の（通常は構成可能）時間後に接続を「忘れる」ため、接続の通信をこれ以上許可しません。彼らは、接続がTCP SYNで始まることを期待しています（ここでSSH通信を参照してください）。
別の可能性があります。自宅とオフィスの間のネットワークパスには、（パケットの種類の）損失がある場合があります。 SSHクライアントで入力しようとしたときに、リンクがしばらく停止していると、クライアントが諦めて失敗する可能性があります。
クライアントのキープアライブ構成は、ここでは最初のケースを処理しますが、2番目のケースでは役立ちません。ファイアウォールは通常、オフィスの境界にあるため、構成可能かもしれません。それも最初の点で役立ちます。
断続的なリンク損失があるかどうかを確認するには、クライアントマシンからバックグラウンドで「ping」をアクティブにしておくことができます。
~/.ssh/configファイルのデフォルトとして他のユーザーが提案した設定を追加することもできるため、接続を開始するたびにsshに渡す必要はありません。
nano ~/.ssh/configと追加：
TCPKeepAlive=no
ServerAliveInterval=15