自宅からオフィスサーバー（Fedora 10を実行）の1つにsshでアクセスすると、かなり短い時間（5分程度）でセッションがタイムアウトします。私はTcpKeepAliveクライアント側で使用してみましたが、効果はありませんでした。
私が理解していないのは、会社のLANのオフィスにいる場合、タイムアウトせずに終日セッションを非アクティブのままにしておくことができるため、動作は私の場所に依存しているように見えることです。
これがなぜ起こっているのか、私がLAN上にいないときにタイムアウトを防ぐ方法はありますか？それが役立つ場合は、Mac OSXでターミナルクライアントを使用しています。
更新 - ServerAliveIntervalゼロ以外のセットを使用するというDave Dragerの提案はTcpKeepAlive=no私のために働いた。他のいくつかの答えについては、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」を実装する方法についての記事があります。
最後に、Wiresharkまたは他のスニファーを使用して実際のTCP接続を監視し、何が起こっているのかを調べることをお勧めします。これが、ときどき切断される理由を確認する最後の方法です。
これはおそらく、自宅から接続しているときにファイアウォールを通過し、しばらくするとTCPセッションを閉じるためです。ただし、TcpKeepAliveはこれを回避する必要があります。クライアント側またはサーバー側でTcpKeepAliveを有効にしましたか？
これは、Comcast接続で常に取得しています。問題は、SSHクライアントのキープアライブ間隔が、ネットワークパスで設定されたタイムアウトに対して長すぎることです。あなたは、Linuxを使っている場合は、変更することができますServerAliveIntervalし、ServerAliveCounterそのデフォルト値よりも低い値を。この値は秒単位で設定されます。システム全体の設定ファイルは（一般に）にあり/etc/ssh/ssh_configます。これら2つのAND TcpKeepAliveを設定すると、接続を維持できます。
radiusが言うように、一部のステートフルファイアウォールは、一定の（通常は構成可能な）時間後に接続を「忘れ」、接続の通信を許可しません。TCP SYNで接続が開始されることを期待しています（ここでSSH通信を参照します）。
別の可能性があります。自宅とオフィスの間のネットワークパスには、（パケットの種類の）損失がある場合があります。SSHクライアントで入力しようとしたときに、リンクがしばらく停止していると、クライアントがgiveめて失敗する可能性があります。
クライアントのキープアライブ構成は、ここで最初のケースを処理しますが、2番目のケースでは役に立ちません。ファイアウォールは通常、オフィスの境界にあるため、構成可能です。それも最初のポイントに役立ちます。
断続的なリンク損失があるかどうかを確認するには、クライアントマシンからバックグラウンドで「ping」をアクティブにしておくことができます。