Network Working Group J. Galbraith
Request for Comments: 4335 VanDyke Software
Category: Standards Track P. Remaker
Cisco Systems, Inc
January 2006
The Secure Shell (SSH) Session Channel Break Extension
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session.
セッションのチャネルブレーク拡張は、セキュアシェル（SSH）ターミナルセッションでBREAK信号を送信するための手段を提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. The Break Request ...............................................3
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................5
The Secure Shell (SSH) [5] session channel provides a mechanism for the client-user to interactively enter commands and receive output from a remote host while taking advantage of the SSH transport's privacy and integrity features. SSH is increasingly being used to replace Telnet for terminal access applications.
セキュアシェル（SSH）[5]セッションチャネルは、対話的にコマンドを入力して、SSHトランスポートのプライバシーと整合性の特徴を生かしながら、リモートホストからの出力を受信するためのクライアント・ユーザーのためのメカニズムを提供します。 SSHはますます端末アクセスアプリケーション用にTelnetを置き換えるために使用されています。
A common application of the Telnet protocol is the "Console Server" [7] whereby a Telnet Network Virtual Terminal (NVT) can be connected to a physical RS-232/V.24 asynchronous port, making the Telnet NVT appear as a locally attached terminal to that port, and making that physical port appear as a network-addressable device. A number of major computer equipment vendors provide high-level administrative functions through an asynchronous serial port and generally expect the attached terminal to be capable of sending a BREAK signal.
Telnetのネットワーク仮想端末（NVT）は、物理RS-232 / V.24非同期ポート、TelnetのNVTを行うに接続することができるTelnetプロトコルの一般的なアプリケーションは、「コンソール・サーバー」である[7]ローカル接続として表示されそのポートに端末、及び物理ポートはネットワークアドレス可能デバイスとして表示されることになります。主要なコンピュータ機器ベンダーの数は、非同期シリアルポートを介してハイレベルの管理機能を提供し、一般に付属端末は、ブレーク信号を送信することができることを期待します。
A BREAK signal is defined as the TxD signal being held in a SPACE ("0") state for a time greater than a whole character time. In practice, a BREAK signal is typically 250 to 500 ms in length.
ブレーク信号は、全キャラクタ時間よりも長い時間のためのスペース（「0」）状態に保持されるのTxD信号として定義されます。実際には、ブレーク信号の長さは、典型的には250〜500ミリ秒です。
The Telnet protocol furnishes a means to send a "BREAK" signal, which RFC 854 [1] defines as "a signal outside the USASCII set which is currently given local meaning within many systems". Console Server vendors interpret the TELNET BREAK signal as a physical BREAK signal, which can then allow access to the full range of administrative functions available on an asynchronous serial console port.
Telnetプロトコルは、RFC 854 [1]「は、現在多くのシステム内のローカルな意味が与えられるUSASCIIセット外部信号」と定義する「BREAK」信号を送信するための手段を供給する。コンソールサーバベンダーは、その後、非同期シリアルコンソールポートで使用可能な管理機能の完全な範囲へのアクセスを可能にすることができる、物理的なBREAK信号としてTELNETのBREAK信号を解釈します。
The lack of a similar facility in the SSH session channel has forced users to continue the use of Telnet for the "Console Server" function.
SSHセッションチャンネルで同様の施設の不足は、「コンソールサーバー」機能のためのTelnetの使用を継続するために、ユーザーを余儀なくされました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[2]で説明されるように解釈されます。
The "byte", "boolean", "uint32", and "string" data types are defined in [3].
「バイト」、「ブール」、「UINT32」、および「文字列」データ型は、[3]で定義されています。
The following channel-specific request can be sent over a session channel (as described in [4]) to request that the remote host perform a BREAK operation.
リモートホストがBREAK操作を実行することを要求する（[4]に記載されているように）次のチャネル固有の要求は、セッションチャネルを介して送信することができます。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "break"
boolean want_reply
uint32 break-length in milliseconds
If the BREAK length cannot be controlled by the application receiving this request, the BREAK length parameter SHOULD be ignored and the default BREAK signal length of the chipset or underlying chipset driver SHOULD be sent.
BREAKの長さがこの要求を受信するアプリケーションによって制御することができない場合、BREAK長パラメータは無視されるべきであり、チップセットまたは基礎チップセットドライバのデフォルトのブレーク信号の長さは送信されるべきです。
If the application receiving this request can control the BREAK length, the following suggestions are made regarding BREAK duration. If a BREAK duration request of greater than 3000 ms is received, it SHOULD be interpreted as a request for a 3000 ms BREAK. This safeguard prevents an unreasonably long BREAK request from causing a port to become unavailable for as long as 49.7 days while executing the BREAK. Applications that require a longer BREAK may choose to ignore this suggestion. If BREAK duration request of less than 500 ms is received, it SHOULD be interpreted as a 500 ms BREAK since most devices will recognize a BREAK of that length. Applications that require a shorter BREAK may choose to ignore this suggestion. If the BREAK length parameter is 0, the BREAK SHOULD be interpreted as the default BREAK signal length of the chipset or underlying chipset driver. If no default exists, 500 ms can be used as the BREAK length.
アプリケーションがBREAKの長さを制御することができ、この要求を受けた場合は、次の提案は、BREAK期間について作られています。より大きい3000ミリ秒のBREAK期間要求を受信した場合は、3000ミリ秒BREAK要求として解釈されるべきです。この安全装置は、BREAKを実行中にポートがある限り49.7として日間使用できなくなることを引き起こしてから不当に長いBREAK要求を防ぎます。長いBREAKを必要とするアプリケーションは、この提案を無視することもできます。 500ms未満の破断時間要求を受信した場合、ほとんどのデバイスは、その長さの切れ目を認識するので、それは500ミリ秒BREAKとして解釈されるべきです。短いBREAKを必要とするアプリケーションは、この提案を無視することもできます。 BREAK長パラメータが0の場合、BREAKは、チップセットまたは基礎となるチップセットドライバのデフォルトのブレーク信号の長さとして解釈されるべきです。デフォルトが存在しない場合は、500ミリ秒はBREAK長として使用することができます。
If the SSH connection does not terminate on a physical serial port, the BREAK indication SHOULD be handled in a manner consistent with the general use of BREAK as an attention/interrupt signal; for instance, a service processor that requires an out-of-band facility to get the attention of a system it manages.
SSH接続は、物理シリアルポートで終了しない場合、BREAK表示が注目/割り込み信号としてBREAKの一般的な使用と一致した方法で処理されるべきです。例えば、アウトオブバンド機能を必要とするサービス・プロセッサーは、管理システムの注意を取得します。
In a case where an SSH connection cascades to another connection, the BREAK SHOULD be passed along the cascaded connection. For example, a Telnet session from an SSH shell should carry along an SSH-initiated BREAK, and an SSH client initiated from a Telnet connection SHOULD pass a BREAK indication from the Telnet connection.
別の接続へのSSH接続カスケード場合に、BREAKは、カスケード接続に沿って通過されるべきです。例えば、SSHシェルからTelnetセッションはSSH-開始BREAKに沿って運ぶ必要があり、Telnet接続から開始SSHクライアントは、Telnet接続からBREAK指示を渡す必要があります。
If the 'want_reply' boolean is set, the server MUST reply using an SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be sent.
「want_reply」ブール値が設定されている場合、サーバはSSH_MSG_CHANNEL_SUCCESS又はSSH_MSG_CHANNEL_FAILURE [5]メッセージを用いて応答しなければなりません。あらゆる種類のBREAKが予備成形された場合は、SSH_MSG_CHANNEL_SUCCESSを送らなければなりません。何BREAKが予備成形されなかった場合は、SSH_MSG_CHANNEL_FAILUREを送らなければなりません。
This operation SHOULD be supported by any general purpose SSH client.
この操作は、任意の汎用SSHクライアントによってサポートされる必要があります。
Many computer systems treat serial consoles as local and secured, and interpret a BREAK signal as an instruction to halt execution of the operating system or to enter privileged configuration modes. Because of this, extra care should be taken to ensure that SSH access to BREAK-enabled ports are limited to users with appropriate privileges to execute such functions. Alternatively, support for the BREAK facility MAY be implemented as configurable on a per-port or per-server basis.
多くのコンピュータシステムは、ローカルおよび担保などのシリアルコンソールを扱い、オペレーティングシステムの実行を停止するか、特権コンフィギュレーションモードを入力するように指示としてBREAK信号を解釈します。このため、特別な注意はしBREAK対応ポートは、このような機能を実行するための適切な権限を持つユーザーに限定されるSSHアクセスを確保するために取られるべきです。また、BREAK機能のサポートは、ポート単位またはサーバ単位で設定可能として実現することができます。
Implementations that literally interpret the BREAK length parameter without imposing the suggested BREAK time limit may cause a denial of service to or unexpected results from attached devices receiving the very long BREAK signal.
文字通り提案BREAK時間制限を課すことなくBREAK長パラメータを解釈する実装は非常に長いBREAK信号を受信接続されたデバイスからのサービス拒否または予期しない結果を引き起こす可能性があります。
IANA has assigned the Connection Protocol Channel Request Name "break" in accordance with [6].
IANAは、[6]に従って接続プロトコルチャンネル要求名「ブレイク」が割り当てられています。
[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[3] Ylonenと、T.とC. Lonvick、エド。、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[4] Ylonenと、T.とC. Lonvick、エド。、 "セキュアシェル（SSH）トランスポート層プロトコル"、RFC 4253、2006年1月。
[5] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[5] Ylonenと、T.とC. Lonvick、エド。、 "セキュアシェル（SSH）接続プロトコル"、RFC 4254、2006年1月。
[6] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[6]レーティネン、S.とC. Lonvick、エド。、 "セキュアシェル（SSH）プロトコル割り当て番号"、RFC 4250、2006年1月。
[7] Harris, D., "Greater Scroll of Console Knowledge", March 2004, <http://www.conserver.com/consoles/>.
[7]ハリス、D.、 "コンソール知識の大スクロール"、2004年3月、<http://www.conserver.com/consoles/>。
Authors' Addresses
著者のアドレス
Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US
ジョセフ・ガルブレイスバンダイクソフトウェア4848路面電車リッジブルバードスイート101アルバカーキ、NM 87111米国
Phone: +1 505 332 5700 EMail: galb-list@vandyke.com
電話：+1 505 332 5700 Eメール：galb-list@vandyke.com
Phillip Remaker Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95120 US
フィリップRemakerシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95120米国
Phone: +1 408 526 8614 EMail: remaker@cisco.com
電話：+1 408 526 8614 Eメール：remaker@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。