RFC 4335 - The Secure Shell (SSH) Session Channel Break Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4335
タイトル : RFC 4335 - セキュアシェル（SSH）セッションチャネルブレークエクステンション
翻訳編集 : 自動生成

[要約] RFC 4335は、SSHセッションチャネルの切断拡張に関するものであり、セッションの切断を安全に行うための仕組みを提供する。目的は、セッションの切断時にデータの損失やセキュリティ上の問題を防ぐこと。

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

セキュアシェル（SSH）セッションチャネルブレークエクステンション

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session.

セッションチャネルブレイク拡張機能は、安全なシェル（SSH）端子セッションにブレーク信号を送信する手段を提供します。

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

1. Introduction

1. はじめに

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.

Secure Shell（SSH）[5]セッションチャネルは、SSH Transportのプライバシーと整合性の機能を利用しながら、クライアントユーザーがインタラクティブにコマンドを入力し、リモートホストから出力を受信するメカニズムを提供します。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プロトコルの一般的なアプリケーションは、「コンソールサーバー」[7]です。これにより、Telnetネットワーク仮想端子（NVT）を物理RS-232/v.24非同期ポートに接続し、Telnet NVTを局所的に添付したように表示します。そのポートの端子、およびその物理的なポートをネットワークアドレス可能なデバイスとして表示します。多くの主要なコンピューター機器ベンダーは、非同期シリアルポートを介して高レベルの管理機能を提供し、通常、添付の端末がブレーク信号を送信できると予想しています。

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.

ブレーク信号は、TXD信号が空間（ "0"）状態に保持されているものとして定義されます。実際には、ブレーク信号の長さは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セットの外側の信号」として定義しています。コンソールサーバーベンダーは、Telnetブレーク信号を物理的なブレーク信号として解釈します。これにより、非同期シリアルコンソールポートで利用可能なあらゆる管理機能へのアクセスが可能になります。

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の使用を継続することを余儀なくされました。

2. Conventions Used in This Document

2. このドキュメントで使用されている規則

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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[2]に記載されているように解釈される。

The "byte", "boolean", "uint32", and "string" data types are defined in [3].

「バイト」、「ブール」、「UINT32」、および「文字列」データ型は[3]で定義されています。

3. The Break Request

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.

次のチャネル固有のリクエストをセッションチャネル（[4]に記載されている）を介して送信して、リモートホストがブレーク操作を実行することを要求できます。

byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "break" boolean want_reply uint32 break-length in milliseconds

BYTE SSH_MSG_CHANNEL_REQUEST UINT32レシピエントチャネル文字

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.

このリクエストを受信するアプリケーションによって破損長を制御できない場合、ブレーク長パラメーターを無視し、チップセットまたは下にあるチップセットドライバーのデフォルトのブレーク信号長を送信する必要があります。

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.

このリクエストを受信するアプリケーションがブレーク長を制御できる場合、ブレーク期間に関して次の提案が行われます。3000ミリ秒を超えるブレーク期間要求を受信した場合、3000ミリ秒の休憩のリクエストとして解釈する必要があります。この保護は、不当に長いブレークリクエストが、ブレークを実行している間、ポートが49.7日間も利用できなくなるのを防ぎます。より長い休憩を必要とするアプリケーションは、この提案を無視することを選択する場合があります。500ミリ秒未満のブレーク期間要求を受信した場合、ほとんどのデバイスがその長さのブレークを認識するため、500ミリ秒の休憩として解釈する必要があります。より短い休憩を必要とするアプリケーションは、この提案を無視することを選択する場合があります。ブレーク長パラメーターが0の場合、ブレークは、チップセットまたは下にあるチップセットドライバーのデフォルトのブレーク信号長として解釈する必要があります。デフォルトが存在しない場合、500ミリ秒をブレーク長として使用できます。

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接続が物理シリアルポートで終了しない場合、ブレーク表示は、注意/割り込み信号としてのブレークの一般的な使用と一致する方法で処理する必要があります。たとえば、管理するシステムの注意を引くためにバンド外の機能を必要とするサービスプロセッサ。

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接続が別の接続にカスケードする場合、カスケード接続に沿ってブレークを渡す必要があります。たとえば、SSHシェルからのTelnetセッションでは、SSH開始ブレークを搭載する必要があり、Telnet接続から開始されたSSHクライアントは、Telnet接続からのブレーク表示を渡す必要があります。

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' booleanが設定されている場合、サーバーはssh_msg_channel_successまたはssh_msg_channel_failure [5]メッセージを使用して返信する必要があります。あらゆる種類の休憩が事前に形成された場合、ssh_msg_channel_successを送信する必要があります。休憩がない場合、ssh_msg_channel_failureを送信する必要があります。

This operation SHOULD be supported by any general purpose SSH client.

この操作は、汎用SSHクライアントによってサポートされる必要があります。

4. Security Considerations

4. セキュリティに関する考慮事項

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.

多くのコンピューターシステムは、シリアルコンソールをローカルおよびセキュリティで扱い、ブレーク信号をオペレーティングシステムの実行を停止する命令として解釈するか、特権構成モードを入力するように解釈します。このため、侵入対応ポートへのSSHアクセスが、そのような機能を実行するための適切な特権を持つユーザーに限定されるように、特別な注意を払う必要があります。あるいは、休憩施設のサポートは、ポートごとまたはサーバーごとに構成可能として実装される場合があります。

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.

推奨される休憩時間制限を課さずにブレーク長パラメーターを文字通り解釈する実装は、非常に長いブレーク信号を受信する添付のデバイスのサービス拒否または予期しない結果を引き起こす可能性があります。

5. IANA Considerations

5. IANAの考慮事項

IANA has assigned the Connection Protocol Channel Request Name "break" in accordance with [6].

IANAは、[6]に従って接続プロトコルチャネルリクエスト名「Break」を割り当てました。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.

[1] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[3] Ylonen、T。およびC. Lonvick、ed。、「The Secure Shell（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、ed。、「The Secure Shell（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、ed。、「The Secure Shell（SSH）接続プロトコル」、RFC 4254、2006年1月。

[6] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.

[6] Lehtinen、S。and C. Lonvick、ed。、「The Secure Shell（SSH）プロトコルに割り当てられた数字」、RFC 4250、2006年1月。

6.2. Informative References

6.2. 参考引用

[7] Harris, D., "Greater Scroll of Console Knowledge", March 2004, <http://www.conserver.com/consoles/>.

[7] Harris、D。、「Greater Scroll of Console Knowledge」、2004年3月、<http://www.conserver.com/consoles/>。

Authors' Addresses

著者のアドレス

Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US

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

Phillip Remaker Cisco Systems、Inc 170 West Tasman Drive San Jose、CA 95120 US

   Phone: +1 408 526 8614
   EMail: remaker@cisco.com

Full Copyright Statement

完全な著作権声明

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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。