SSHで接続していて、何もしない時間が長くなった場合に、いつの間にか切断されていたりします。
特に、デバッグ作業などのためにコンソールから起動しっぱなしの状態で放っておいた場合などは、いつの間にかブチっと切れていることがあります。
今回は、この原因と対処について、簡単に解説してみます。
- 目次
- 履歴
2013年3月8日 初版
SSHが自動的に切断される要因とその対処について
SSHが自動的に切断される原因とその対処について、簡単に解説してみます。
[原因]
自宅や会社でSSH接続するホストまでに、ルーターを介してしませんか?
まず、間違いなくSSH接続が自動的に切断されてしまう要因は、ルーターに起因しているでしょう。
ルーターは、少ないリソース(ほとんどの場合は1つの外向けの回線)を NATの技術を用いて 最大限活用しようとします。
その場合、NATで外部接続されている回線の中で、パケットがある一定時間流れなかった場合は、自動的に切断するようになっていることがほとんどです。
無駄に接続されていると判断して、他のユーザへその回線(リソース)を譲るべく切断するわけです。
切断されてしまうと、SSHクライアントは、次に何らかのアクションを起こすまで、切断されていることに気づきません。
逆にサーバーからのパケットは、受けれませんから、仮にサーバーから情報伝送された場合、失敗するわけです。
[対処]
対処には、いくつかの方法があります。
- ルーターの設定で、自動切断しないようにする
→ 確かに自動切断しないようにすれば回避できますが、TCPポート、IPアドレスなどで条件を付けて設定する必要があります。
(ルーターの設定は、各メーカー、機種によって様々ですので、ここでの詳細な解説について割愛します。)
- Windowsなら、SSHクライアントソフトを使う
→ TeraTerm や puttyなどの有名なSSHクライアントソフトには、NULLパケットを定期的に送信する機能があります。その機能を有効にしていれば、自動切断されることはなくなるでしょう。
以下は、TeraTerm の設定例です。
- メニューの [設定] – [SSH] をクリックします。
- ハートビートに適当な秒数を設定します。
デフォルト60秒なので、ほとんどの場合は、60を設定しておけばOKのはずです。
もし、既に60秒になっているのに、自動的に切断される現象が発生しているなら、秒数を短くしてやってみましょう。それでも変化がない場合は、他の要因が考えられます。
- メニューの [設定] – [SSH] をクリックします。
- SSHD(SSHのデーモンプロセス)の設定を変更する
→ SSHD(サーバー)から接続中のクライアントに対して、一定間隔でパケットを流して接続確認を行うように設定することができます。
以下は、SSHDの設定ファイル( /etc/ssh/sshd_config ) の設定例です。
... ClientAliveInterval 60 ClientAliveCountMax 3 ...
ClientAliveIntervalsshd は一定時間ごとに、暗号化された通信路を経由してクライアントに応答を要求するメッセージ(client alive message) を送ります。 その際、何もデータが送られてこなかったらタイムアウトする時間を秒数で指定します。 デフォルトの値は 0 で、これはメッセージを送らないことを意味します。 この設定項目は プロトコル バージョン 2 でのみサポートされています。
(出典 : SSHD_CONFIG マニュアル)
ClientAliveCountMaxsshd が無反応のクライアントに対してclient alive message (下記参照) を送ってみる最大数を指定します。 client alive message に対する応答が連続してこの回数だけなかった場合、sshd は接続を切り、セッションを終了します。 client alive message は、TCPKeepAlive(下記) とはまったく違うことに注意してください。 client alive message は暗号化された経路を介して送られるので、偽造されることはありません。 TCPKeepAliveによって設定される TCP の keepalive オプションは偽造される可能性があります。 client alive のメカニズムはクライアントあるいはサーバが、いつ接続が切れたのかを知りたいときに役立ちます。
デフォルトの値は 3 です。 もしClientAliveInterval(上記) が 15 に設定され、ClientAliveCountMaxがデフォルトのままである場合、 これに反応できない SSH クライアントはおよそ 45 秒後に接続が切られます。 この設定項目は プロトコル バージョン 2 でのみサポートされています。
(出典 : SSHD_CONFIG マニュアル)
ここの例では、何もリアクションがない時間が 60 x 3 = 180 (秒) = 3分以上になったら、自動切断されることになります。
編集を終えたら、再読み込みを実行します。
$ /etc/init.d/sshd reload ...
- SSH(SSHのクライアント)の設定を変更する
→ SSH(クライアント)から接続中のサーバーに対して、一定間隔でパケットを流して接続確認を行うように設定することができます。
以下は、SSHの設定ファイル( /etc/ssh/ssh_config ) の設定例です。
... ServerAliveInterval 60 ServerAliveCountMax 3 ...
ServerAliveInterval一定期間サーバからデータが送られてこないときに、タイムアウトする秒数を設定します。 この場合 ssh は 暗号化された通信路を介してサーバ側に返答を要求するメッセージを送ります。 デフォルトは 0 で、これはこのようなメッセージをサーバ側に送らないことを指示しています。 この設定項目は プロトコル バージョン 2 でのみ有効です。
(出典 : SSH_CONFIG マニュアル)
ServerAliveCountMaxssh が サーバからの返答を確認するまでに、サーバ生存確認メッセージ (下記参照)を何回まで送るかを指定します。 この回数が指定された数値を超えると、ssh はサーバ側との接続を切断し、セッションを終了させます。 重要なのは、サーバ生存確認メッセージは以下に記されているTCPKeepAliveとはまったく違うということです。 サーバ生存確認メッセージは暗号化された通信路を経由して送られるので、偽装可能ではありません。 これに対して、TCPKeepAliveで指定される TCP の keepalive オプションは偽装が可能です。 このサーバ生存確認の機構は、クライアントまたはサーバ側が、いつ接続が切れたかを知りたいときに有用です。
このデフォルト値は、 3 です。 たとえばもし、ServerAliveInterval(上記) が 15 に設定されており、ServerAliveCountMaxがデフォルトのままだったとしたら、 ssh はサーバが応答しなくなった後およそ 45 秒後に接続を切断します。 この設定項目はプロトコル バージョン 2 にのみ適用されます。
(出典 : SSH_CONFIG マニュアル)
ここの例では、何もリアクションがない時間が 60 x 3 = 180 (秒) = 3分以上になったら、自動切断されることになります。
この設定では、SSHクライアント全体に対してい影響します。 個別のユーザだけに対応させたい場合は、各ユーザホームディレクトリの
~/.ssh/config
を同じように編集すると良いでしょう。
ここでの対処で、色々と記述していますが、ここで注意してほしいのは、
SSHDサーバーから自動切断することは、設定を意図的に行わないとありえないということです。
SSHクライアントからも、自動的に切断することは、まず、ありえないでしょう。
ServerAliveInterval、ClientAliveIntervalは、いずれもデフォルト0で自動切断しないようになっています。
また、TCPKeepAlive は、ある一定間隔でクライアント、サーバー間で接続確認のパケットを送受信し、TCPソケットを接続維持する機能で、確かに、デフォルトでONとなっています。
しかし、このTCPKeepAlive は、接続確認するデフォルトの時間は、約2時間程度になっているはずです。その時間は、以下のように確認することができます。
|
7200 (秒) = 2 (時間) となっています。
このように、意図的に上記のような設定項目を変更していない限り、自動的に切断されることはありません。
少なくとも2時間程度は、です。
この他にもDebian個別のSSH設定で、以下のようなものがあります。
|
ProtocolKeepAlives and SetupTimeOut are Debian-specific compatibility aliases for this option.とあります。
つまりは、ServerAliveIntervalのDebian固有の別名(alias)ということのようです。
色々なサイトに、ProtocolKeepAlives の記述がありますが、このことからすれば、Debianユーザであっても ServerAliveInterval を使っていた方が後々良さそうです。
このサイトでは、コンテンツの一部が非表示、あるいは、コメント、お問い合わせの投稿ができない、検索ができないことがあります。
コメントを投稿 :