Network Working Group J. Galbraith Request for Comments: 4335 VanDyke Software Category: Standards Track P. Remaker Cisco Systems, Inc January 2006 セキュアシェル (SSH) セッションチャンネルBreak拡張 このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 セッションチャンネルBreak拡張は, セキュアシェル(SSH)のターミナルセッションで BREAK シグナルを送る手段を提供する. 目次 1イントロダクション ..........................................2 2. この文書で用いる表記 ...............................2 3. Break 要求 ...............................................3 4. セキュリティの考察 .........................................4 5. INANの考慮 .............................................4 6. References ......................................................4 6.1. Normative References .......................................4 6.2. Informative References .....................................5 Galbraith & Remaker Standards Track [Page 1] RFC 4335 SSH Break Extension January 2006 1イントロダクション セキュアシェル (SSH) [5] セッションチャンネルは, SSHのトランスポートの秘密性と完全性の特徴を利用しながら, クライアントユーザにインタラクティブにコマンドを入力しリモートホストから出力を受けるメカニズムを提供する. SSH は ターミナルアクセスアプリケーションとして Telnet を置き換えるためにだんだんと使われ出している. Telnet プロトコルの共通のアプリケーションに "Console Server" [7] がある. これにより, Telnet Network Virtual Terminal (NVT) は, 物理 RS-232/V.24 非同期ポートに接続されると, この Telnet NVT は そのポートにローカルに接続されたように見え, その物理ポートは ネットワークのアドレスを持つデバイスのようにみえる. 多数のメジャーな計算機機器ベンダーが, 非同期シリアルポートを通じた高レベルの管理機能を提供している. そして, 接続されたターミナルに BREAK シグナルを送る能力があることを一般的に期待している. BREAK シグナルは, 全体のキャラクタ時間よりも長い間 SPACE ("0") 状態を保持する TxD 信号として定義される. 実際には, BREAK 信号は典型的に 250から500 msの長さだ . Telnet プロトコルは, "BREAK" 信号を送る方法を提供している. RFC 854[1]で次のように定義している "多くのシステムで現在ローカルな意味を与えられているUSASCIIの集合の外部にある信号". Console Server のベンダーは, TELNET BREAK 信号を 物理的な BREAK 信号として解釈する. これにより, 非同期シリアルコンソールポートで利用可能な管理機能のすべての範囲へのアクセスを可能にする. SSH セッションチャンネルで似た機能がないことは, "Console Server"機能のためにTelnetを用い続けることをユーザに強いてきた. 2. この文書で用いる表記 この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [2] で記述されているように解釈される. "byte" や "boolean", "uint32", "string" データタイプは [3] で定義されている. Galbraith & Remaker Standards Track [Page 2] RFC 4335 SSH Break Extension January 2006 3. Break 要求 次のチャンネル特有のリクエストが, リモートホストで BREAK 操作を行なう要求のために ([4] で記述されている) セッションチャンネル上で送られる. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "break" boolean want_reply uint32 break-length in milliseconds この要求を受けるアプリケーションが BREAK の長さを制御できないなら, BREAK length パラメータは, 無視される必要がある. チップセットや基盤となるチップセットのドライバのデフォルトの BREAK シグナルの長さが送られなければならない. このリクエストを受けるアプリケーションが BREAK の長さを制御できるなら, BREAKの持続時間について, 次の示唆がある. 3000 ms を越える BREAK 持続時間の要求を受け取ったら, 3000 ms の BREAKと解釈される必要がある. この予防手段は, 理不尽に長い BREAK 要求が BREAKを実行する間に49.7日の間ポートを利用不能にするのを防ぐ. より長い BREAKを必要とするアプリケーションは, この示唆を無視してもよい. BREAKの持続時間が 500 msよりも小さいリクエストを受け取ったら, 500 ms BREAK と解釈される必要がある. 多くのデバイスでこの長さが BREAKと認識されるからだ. より短い BREAKを必要とするアプリケーションは, この示唆を無視してもよい. BREAK length parameter が 0 なら, チップセットや基盤となるチップセットのドライバのデフォルトの BREAK シグナルの長さと解釈される. デフォルトがなければ, 500msが BREAK の長さとして用いられる. SSH 接続が物理シリアルポートで終了されないなら, BREAKの表示は, 注意/割り込みのシグナルとしてのBREAKの一般的な利用法と合致する方法で取り扱わなければならない. たとえば, 管理するシステムの注意を引くために帯域外の機能を要求するサービスプロセッサだ. SSHの接続が別の接続にカスケードされている場合は, BREAKはカスケードされた接続に渡される必要がある. たとえば, SSH シェルからのTelnetセッションは, SSHを起点とする BREAK を転送する必要がある. Telnet 接続で始められた SSH クライアントは Telnet 接続からの BREAK 表示を転送する必要がある. Galbraith & Remaker Standards Track [Page 3] RFC 4335 SSH Break Extension January 2006 'want_reply' が設定されていたら, サーバは SSH_MSG_CHANNEL_SUCCESS か SSH_MSG_CHANNEL_FAILURE [5] メッセージを用いて応答しなければならない. なんらかの BREAK が実行されたら, SSH_MSG_CHANNEL_SUCCESS が送られなければならない. BREAK が実行されなかったら, SSH_MSG_CHANNEL_FAILURE が送られなければならない. この操作を, 一般的な目的のSSHクライアントはサポートする必要がある. 4. セキュリティの考察 多くの計算機システムは, シリアルコンソールをローカルで安全なものと取り扱う. そして BREAK 信号を オペレーティングシステムの中断の実施や特権設定モードへ進入の指示として解釈する. このため, BREAKが有効なポートへのSSHのアクセスがこれらの機能を実行するための適切な権限を持つユーザに限定されていることを, 非常に注意する必要がある. また, BREAK 機能のサポートは, ポート単位やサービス単位のベースで設定可能に実装されてもよい. 示唆した BREAK時間の制限を行なわなず BREAK length パラメータのまま解釈する実装は, 非常に長い BREAK 信号を受けて , 接続したデバイスからサービス不能や予期しない結果になるかもしれない. 5. IANA の考慮 IANA は, [6] に従って このコネクションプロトコルチャンネルの要求名を "break" と割り当てた. 6. References 6.1. Normative References [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [5] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. Galbraith & Remaker Standards Track [Page 4] RFC 4335 SSH Break Extension January 2006 [6] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. 6.2. Informative References [7] Harris, D., "Greater Scroll of Console Knowledge", March 2004, . Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Phillip Remaker Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95120 US Phone: +1 408 526 8614 EMail: remaker@cisco.com Galbraith & Remaker Standards Track [Page 5] RFC 4335 SSH Break Extension January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Galbraith & Remaker Standards Track [Page 6]