ログインしっぱなしで10分ほど放置しておくと接続が切れる環境があります。筆者の職場がそうです。いろいろな解決方法が提案されています。それぞれの方法の概略と問題点についてまとめてみます。対処方法をリストアップします。見かけ上はSSHでログインした先のシェルが無反応になります。SSHクライアントが接続断を認識します。NATテーブルをクリアしてしまうために起こると考えられます。少なくとも職場のブロードバンドルータは何もしないようです)。意図的に切断している環境もあるでしょう。同じように切れるはずですが、SSH以外はまず該当しないでしょう。ような気がしますが、これは後述するように全く効果がありません。有効な方法は以下のようにいくつかありますが、どれもメリットとデメリットがあります。SSH接続を放置しないルータの設定をなんとかするログイン先で定期的に何かを出力するプログラムを実行するKeepAliveが期待通り動くようにOSのTCP設定を変更するSSHサーバの設定で切れているかどうか確認するパケットを送るSSHクライアントの設定で無害なパケットを定期的に送るまた、SSH接続の際に接続先の端末(tty)が必要かどうかによっても対策は変わってきます。適用の可否が変わってきます。表にまとめると次のようになります。以下、上記の方法の詳細と問題点・適用範囲について説明していきます。SSH接続を放置しないログインして使う場合は、用が済んだらexitしましょう。汎用的でかつセキュリティ的にも文句のない方法です。筆者には絶対に無理です。ルータの設定をなんとかするルータのタイムアウト設定を延ばすのが一番まともな解決方法です。クリアするまでの時間を非常に長くすればOKということになります。適用できない可能性もあります。問題としては変わっていないともいえます。300などとリモートで実行する例がよく見られます。問題点は、他のプロセスの出力と混ざってしまうことです。このバックグラウンドプロセスの出力が画面を乱してしまいます。うるさいのでイマイチだと思います。yesとしただけではこの問題は解決しません。接続が生きているかどうかを確認するためのパケットを流すものです。とっくに切れているくらいの時間が経過してようやく接続断をOSが認識するわけです。いうものなのでしょう。問題は解決するようですが、心理的に抵抗があります。アプリケーションレベルで対処すべき問題のように思います。切断しているかどうかを確認する目的で定期的にパケットを送ることができます。これは比較的問題の少ない方法だと思います。問題になることはまず無いでしょう。プロトコルがSSH2でないと利用できないことです。ポートフォワーディング用途には使えません。メンテナンスするサーバマシンが増えるたびにこの設定をするのも面倒です。個人的にはこれがオススメです。以下のように書くことで300秒に1回無害なパケットを流します。300他にも、以下のクライアントにはこの機能が標準でついているようです。上記のHeartbeatパッチを拾ってきてコンパイルし直す必要があります。Heartbeatと同じ機能がProtocolKeepAlivesという名前になっているようです。本質的な部分は10行程度のようです。ソースさえあれば対応可能だと思います。個人的には杞憂だろうと思っています。上記パッチの内容が標準装備されているそうです。woodyを長く使っていたこともあり気付いていませんでした。HeartBeatに対応しているそうです。対応しているみたいです。