[要約] RFC 4254は、セキュアシェル (SSH) 接続プロトコルに関する文書で、SSHセッション中にデータ交換を安全に行うための方法を定義しています。このプロトコルは、リモートコンピュータへの安全なログイン、コマンド実行、ファイル転送などに利用されます。関連するRFCには、RFC 4251（SSHプロトコルアーキテクチャ）、RFC 4252（SSH認証プロトコル）、RFC 4253（SSHトランスポート層プロトコル）があり、これらはSSHプロトコルスイートを構成する重要な部分です。
Network Working Group T. Ylonen
Request for Comments: 4254 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Connection Protocol
セキュアシェル（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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
セキュアシェル（SSH）は、安全でないリモートログインや、安全でないネットワークを介したその他の安全なネットワークサービスのためのプロトコルです。
This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.
このドキュメントでは、SSH接続プロトコルについて説明します。対話型ログインセッション、コマンドのリモート実行、転送されたTCP / IP接続、および転送されたX11接続を提供します。これらのチャネルはすべて、単一の暗号化されたトンネルに多重化されます。
The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols.
SSH接続プロトコルは、SSHトランスポート層およびユーザー認証プロトコルの上で実行するように設計されています。
Table of Contents
目次
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
4. Global Requests .................................................4
5. Channel Mechanism ...............................................5
5.1. Opening a Channel ..........................................5
5.2. Data Transfer ..............................................7
5.3. Closing a Channel ..........................................9
5.4. Channel-Specific Requests ..................................9
6. Interactive Sessions ...........................................10
6.1. Opening a Session .........................................10
6.2. Requesting a Pseudo-Terminal ..............................11
6.3. X11 Forwarding ............................................11
6.3.1. Requesting X11 Forwarding ..........................11
6.3.2. X11 Channels .......................................12
6.4. Environment Variable Passing ..............................12
6.5. Starting a Shell or a Command .............................13
6.6. Session Data Transfer .....................................14
6.7. Window Dimension Change Message ...........................14
6.8. Local Flow Control ........................................14
6.9. Signals ...................................................15
6.10. Returning Exit Status ....................................15
7. TCP/IP Port Forwarding .........................................16
7.1. Requesting Port Forwarding ................................16
7.2. TCP/IP Forwarding Channels ................................18
8. Encoding of Terminal Modes .....................................19
9. Summary of Message Numbers .....................................21
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................22
Authors' Addresses ................................................23
Trademark Notice ..................................................23
The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols ([SSH-TRANS] and [SSH-USERAUTH]). It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections.
SSH接続プロトコルは、SSHトランスポート層およびユーザー認証プロトコル（[SSH-TRANS]および[SSH-USERAUTH]）の上で実行するように設計されています。対話型ログインセッション、コマンドのリモート実行、転送されたTCP / IP接続、および転送されたX11接続を提供します。
The 'service name' for this protocol is "ssh-connection".
このプロトコルの「サービス名」は「ssh-connection」です。
This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
このドキュメントは、SSHアーキテクチャドキュメント[SSH-ARCH]を読んだ後にのみ読む必要があります。このドキュメントでは、アーキテクチャドキュメントの用語と表記を自由に使用し、参照や詳細な説明はありません。
The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions.
このドキュメントセットの主要な元の貢献者は、Tatu Ylonen、Tero Kivinen、Timo J. Rinne、Sami Lehtinen（SSH Communications Security Corpのすべて）、およびMarkku-Juhani O. Saarinen（Jyvaskyla大学）です。ダレンモファットは、この一連のドキュメントの最初の編集者であり、非常に大きな貢献もしました。
Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it.
このドキュメントの開発には、長年にわたって多くの人々が貢献してくれました。認められるべき人には、マット・アンダーソン、ベン・ハリス、ビル・ソマーフェルト、ブレント・マクルーア、ニールス・モラー、ダミアン・ミラー、デレク・フォーカス、フランク・カザック、ヘイッキ・ノイシャイネン、ジェイコブ・シュリター、ジェフ・ヴァン・ダイク、ジェフリー・アルトマン、ジェフリー・ハッツェルマン、ジョン・ブライト、ジョセフガルブレイス、ケンホーンスタイン、マーカスフリードル、マーティンフォーセン、ニコラスウィリアムズ、ニールスプロボス、ペリーメッツガー、ピーターグトマン、サイモンジョセフソン、サイモンタサム、ウェイダイ、デニスビダー、マウス、デアマウス、河野忠義。ここに彼らの名前をリストすることは、彼らがこの文書を支持することを意味するのではなく、彼らがそれに貢献したことを意味します。
All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119].
SSHプロトコルに関連するすべてのドキュメントは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」を使用するものとします。要件を説明する「オプション」。これらのキーワードは、[RFC2119]で説明されているように解釈されます。
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434].
このドキュメントに表示されるキーワード「プライベート使用」、「階層割り当て」、「ファーストカムファーストサーブド」、「エキスパートレビュー」、「仕様が必要」、「IESG承認」、「IETFコンセンサス」、および「標準アクション」名前空間の割り当てを説明するために使用されるものは、[RFC2434]で説明されているように解釈されます。
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
プロトコルフィールドと、フィールドに入力できる値は、この一連のドキュメントで定義されています。プロトコルフィールドはメッセージ定義で定義されます。例として、SSH_MSG_CHANNEL_DATAは次のように定義されます。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
バイトSSH_MSG_CHANNEL_DATA uint32受信者チャネル文字列データ
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
これらのドキュメント全体で、フィールドが参照されている場合、フィールドは一重引用符で囲まれています。それらのフィールドを満たす値が参照される場合、それらは二重引用符で囲まれて表示されます。上記の例を使用すると、「data」の可能な値は「foo」と「bar」です。
There are several kinds of requests that affect the state of the remote end globally, independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. Note that both the client and server MAY send global requests at any time, and the receiver MUST respond appropriately. All such requests use the following format.
チャネルに関係なく、リモートエンドの状態にグローバルに影響を与える要求にはいくつかの種類があります。例は、特定のポートのTCP / IP転送を開始する要求です。クライアントとサーバーの両方がいつでもグローバルリクエストを送信する可能性があり、レシーバーは適切に応答する必要があることに注意してください。このようなリクエストはすべて次の形式を使用します。
byte SSH_MSG_GLOBAL_REQUEST
string request name in US-ASCII only
boolean want reply
.... request-specific data follows
The value of 'request name' follows the DNS extensibility naming convention outlined in [SSH-ARCH].
「リクエスト名」の値は、[SSH-ARCH]で概説されているDNS拡張性命名規則に従います。
The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is TRUE.
受信者は、「返信を希望」がTRUEの場合、SSH_MSG_REQUEST_SUCCESSまたはSSH_MSG_REQUEST_FAILUREでこのメッセージに応答します。
byte SSH_MSG_REQUEST_SUCCESS
.... response specific data
Usually, the 'response specific data' is non-existent.
通常、「応答固有のデータ」は存在しません。
If the recipient does not recognize or support the request, it simply responds with SSH_MSG_REQUEST_FAILURE.
受信者がリクエストを認識またはサポートしない場合、SSH_MSG_REQUEST_FAILUREで応答します。
byte SSH_MSG_REQUEST_FAILURE
バイトSSH_MSG_REQUEST_FAILURE
In general, the reply messages do not include request type identifiers. To make it possible for the originator of a request to identify to which request each reply refers, it is REQUIRED that replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as the corresponding request messages. For channel requests, replies that relate to the same channel MUST also be replied to in the right order. However, channel requests for distinct channels MAY be replied to out-of-order.
通常、応答メッセージには要求タイプIDが含まれていません。要求の発信者が各応答がどの要求を参照するかを識別できるようにするには、SSH_MSG_GLOBAL_REQUESTSへの応答を、対応する要求メッセージと同じ順序で送信する必要があります。チャネル要求の場合、同じチャネルに関連する応答も正しい順序で応答する必要があります。ただし、個別のチャネルに対するチャネル要求は、順不同で応答される場合があります。
All terminal sessions, forwarded connections, etc., are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection.
すべての端末セッション、転送された接続などはチャネルです。どちら側でもチャネルを開くことができます。複数のチャネルが単一の接続に多重化されます。
Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to open a channel contain the sender's channel number. Any other channel-related messages contain the recipient's channel number for the channel.
チャネルは両端の番号で識別されます。チャネルを参照する番号は、両側で異なる場合があります。チャネルを開く要求には、送信者のチャネル番号が含まれています。その他のチャネル関連メッセージには、チャネルの受信者のチャネル番号が含まれています。
Channels are flow-controlled. No data may be sent to a channel until a message is received to indicate that window space is available.
チャネルはフロー制御されます。ウィンドウスペースが利用可能であることを示すメッセージが受信されるまで、チャネルにデータを送信できません。
When either side wishes to open a new channel, it allocates a local number for the channel. It then sends the following message to the other side, and includes the local channel number and initial window size in the message.
いずれかの側が新しいチャネルを開きたい場合、チャネルにローカル番号を割り当てます。次に、次のメッセージを相手側に送信し、ローカルチャネル番号と初期ウィンドウサイズをメッセージに含めます。
byte SSH_MSG_CHANNEL_OPEN
string channel type in US-ASCII only
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
The 'channel type' is a name, as described in [SSH-ARCH] and [SSH-NUMBERS], with similar extension mechanisms. The 'sender channel' is a local identifier for the channel used by the sender of this message. The 'initial window size' specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. The 'maximum packet size' specifies the maximum size of an individual data packet that can be sent to the sender. For example, one might want to use smaller packets for interactive connections to get better interactive response on slow links.
「チャネルタイプ」は、[SSH-ARCH]と[SSH-NUMBERS]で説明されている名前であり、同様の拡張メカニズムを備えています。 「送信者チャネル」は、このメッセージの送信者が使用するチャネルのローカル識別子です。 「初期ウィンドウサイズ」は、ウィンドウを調整せずにこのメッセージの送信者に送信できるチャネルデータのバイト数を指定します。 「最大パケットサイズ」は、送信者に送信できる個々のデータパケットの最大サイズを指定します。たとえば、対話型接続に小さいパケットを使用して、低速リンクでの対話型応答を向上させることができます。
The remote side then decides whether it can open the channel, and responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
リモート側は、チャネルを開くことができるかどうかを決定し、SSH_MSG_CHANNEL_OPEN_CONFIRMATIONまたはSSH_MSG_CHANNEL_OPEN_FAILUREのいずれかで応答します。
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
The 'recipient channel' is the channel number given in the original open request, and 'sender channel' is the channel number allocated by the other side.
「受信側チャネル」は元のオープンリクエストで指定されたチャネル番号であり、「送信側チャネル」は相手側によって割り当てられたチャネル番号です。
byte SSH_MSG_CHANNEL_OPEN_FAILURE uint32 recipient channel uint32 reason code string description in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
バイトSSH_MSG_CHANNEL_OPEN_FAILURE uint32受信者チャネルuint32理由コード文字列の説明（ISO-10646 UTF-8エンコーディング[RFC3629]文字列言語タグ[RFC3066]）
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support the specified 'channel type', it simply responds with SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the 'description' string to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH].
SSH_MSG_CHANNEL_OPENメッセージの受信者が指定された「チャネルタイプ」をサポートしていない場合は、SSH_MSG_CHANNEL_OPEN_FAILUREで応答します。クライアントは「説明」文字列をユーザーに表示してもよい（MAY）。これが行われる場合、クライアントソフトウェアは[SSH-ARCH]で説明されている予防措置を取る必要があります。
The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in the following table. Note that the values for the 'reason code' are given in decimal format for readability, but they are actually uint32 values.
SSH_MSG_CHANNEL_OPEN_FAILUREの「理由コード」の値は、次の表で定義されています。 「理由コード」の値は読みやすいように10進形式で指定されていますが、実際にはuint32値です。
Symbolic name reason code
------------- -----------
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code' values (and associated 'description' text) in the range of 0x00000005 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Channel Connection Failure 'reason code' values in the range of 0xFE000000 to 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
[RFC2434]で説明されているように、0x00000005から0xFDFFFFFFの範囲の新しいSSH_MSG_CHANNEL_OPEN '理由コード'値（および関連する '説明'テキスト）の割り当て要求は、IETF CONSENSUSメソッドを介して実行する必要があります。 IANAは、0xFE000000から0xFFFFFFFFの範囲のチャネル接続障害の「理由コード」値を割り当てません。 [RFC2434]で説明されているように、その範囲のチャネル接続障害の「理由コード」値は、プライベート使用のために残されます。
While it is understood that the IANA will have no control over the range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two parts and administered by the following conventions.
IANAは0xFE000000〜0xFFFFFFFFの範囲を制御できないことが理解されていますが、この範囲は2つの部分に分割され、次の規則によって管理されます。
o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction with locally assigned channels. For example, if a channel is proposed with a 'channel type' of "example_session@example.com", but fails, then the response will contain either a 'reason code' assigned by the IANA (as listed above and in the range of 0x00000001 to 0xFDFFFFFF) or a locally assigned value in the range of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does not understand the proposed 'channel type', even if it is a locally defined 'channel type', then the 'reason code' MUST be 0x00000003, as described above, if the 'reason code' is sent. If the server does understand the 'channel type', but the channel still fails to open, then the server SHOULD respond with a locally assigned 'reason code' value consistent with the proposed, local 'channel type'. It is assumed that practitioners will first attempt to use the IANA assigned 'reason code' values and then document their locally assigned 'reason code' values.
o 0xFE000000〜0xFEFFFFFFの範囲は、ローカルに割り当てられたチャネルと組み合わせて使用されます。たとえば、「example_session@example.com」の「チャネルタイプ」で提案されたチャネルが失敗した場合、応答にはIANAによって割り当てられた「理由コード」が含まれます0x00000001〜0xFDFFFFFF）または0xFE000000〜0xFEFFFFFFの範囲でローカルに割り当てられた値。当然、サーバーが提案された「チャネルタイプ」を理解しない場合、それがローカルに定義された「チャネルタイプ」であっても、「理由コード」が送信される場合、上記のように「理由コード」は0x00000003でなければなりません。サーバーが「チャネルタイプ」を理解しても、チャネルがまだ開かない場合、サーバーは、提案されたローカルの「チャネルタイプ」と一致するローカルに割り当てられた「理由コード」値で応答する必要があります。開業医はまずIANAが割り当てた「理由コード」の値を使用しようとし、次にローカルに割り当てられた「理由コード」の値を文書化することを想定しています。
o There are no restrictions or suggestions for the range starting with 0xFF. No interoperability is expected for anything used in this range. Essentially, it is for experimentation.
o 0xFFで始まる範囲に制限や提案はありません。この範囲で使用されるものの相互運用性は期待されていません。基本的に、それは実験用です。
The window size specifies how many bytes the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window.
ウィンドウサイズは、ウィンドウが調整されるのを待つ必要がある前に相手が送信できるバイト数を指定します。どちらの側も次のメッセージを使用してウィンドウを調整します。
byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 recipient channel uint32 bytes to add
追加するバイトSSH_MSG_CHANNEL_WINDOW_ADJUST uint32受信者チャネルuint32バイト
After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Implementations MUST correctly handle window sizes of up to 2^32 - 1 bytes. The window MUST NOT be increased above 2^32 - 1 bytes.
このメッセージを受信した後、受信者は、以前に送信を許可されていたバイト数よりも多くのバイトを送信できます（MAY）。ウィンドウサイズが増加します。実装では、最大2 ^ 32-1バイトのウィンドウサイズを正しく処理する必要があります。ウィンドウを2 ^ 32-1バイトより大きくしてはいけません。
Data transfer is done with messages of the following type.
データ転送は、次のタイプのメッセージで行われます。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
バイトSSH_MSG_CHANNEL_DATA uint32受信者チャネル文字列データ
The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty.
許可されるデータの最大量は、チャネルの最大パケットサイズと現在のウィンドウサイズのどちらか小さい方によって決まります。ウィンドウサイズは、送信されたデータの量によって減少します。両方の当事者は、許可されたウィンドウが空になった後に送信されるすべての余分なデータを無視してもよい（MAY）。
Implementations are expected to have some limit on the SSH transport layer packet size (any limit for received packets MUST be 32768 bytes or larger, as described in [SSH-TRANS]). The implementation of the SSH connection layer
実装では、SSHトランスポート層のパケットサイズに制限があることが予想されます（[SSH-TRANS]で説明されているように、受信パケットの制限は32768バイト以上にする必要があります）。 SSH接続層の実装
o MUST NOT advertise a maximum packet size that would result in transport packets larger than its transport layer is willing to receive.
o そのトランスポート層が受信する意思があるよりも大きいトランスポートパケットをもたらす最大パケットサイズをアドバタイズしてはなりません。
o MUST NOT generate data packets larger than its transport layer is willing to send, even if the remote end would be willing to accept very large packets.
o リモートエンドが非常に大きなパケットを受け入れる用意がある場合でも、トランスポート層が送信する用意があるよりも大きなデータパケットを生成してはなりません。
Additionally, some channels can transfer several types of data. An example of this is stderr data from interactive sessions. Such data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate integer specifies the type of data. The available types and their interpretation depend on the type of channel.
さらに、いくつかのチャネルはいくつかのタイプのデータを転送できます。この例は、インタラクティブセッションからのstderrデータです。このようなデータは、SSH_MSG_CHANNEL_EXTENDED_DATAメッセージで渡すことができます。ここで、個別の整数はデータのタイプを指定します。使用可能なタイプとその解釈は、チャネルのタイプによって異なります。
byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient channel uint32 data_type_code string data
バイトSSH_MSG_CHANNEL_EXTENDED_DATA uint32受信者チャネルuint32 data_type_code文字列データ
Data sent with these messages consumes the same window as ordinary data.
これらのメッセージで送信されるデータは、通常のデータと同じウィンドウを消費します。
Currently, only the following type is defined. Note that the value for the 'data_type_code' is given in decimal format for readability, but the values are actually uint32 values.
現在、以下のタイプのみが定義されています。 'data_type_code'の値は読みやすいように10進数形式で指定されていますが、実際の値はuint32値です。
Symbolic name data_type_code
------------- --------------
SSH_EXTENDED_DATA_STDERR 1
Extended Channel Data Transfer 'data_type_code' values MUST be assigned sequentially. Requests for assignments of new Extended Channel Data Transfer 'data_type_code' values and their associated Extended Channel Data Transfer 'data' strings, in the range of 0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS method as described in [RFC2434]. The IANA will not assign Extended Channel Data Transfer 'data_type_code' values in the range of 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 'data_type_code' values in that range are left for PRIVATE USE, as described in [RFC2434]. As is noted, the actual instructions to the IANA are in [SSH-NUMBERS].
拡張チャネルデータ転送 'data_type_code'の値は、連続して割り当てる必要があります。 [RFC2434]で説明されているように、0x00000002から0xFDFFFFFFの範囲の新しい拡張チャネルデータ転送 'data_type_code'値とそれらに関連付けられた拡張チャネルデータ転送 'データ'文字列の割り当て要求は、IETF CONSENSUSメソッドを介して実行する必要があります。 IANAは、0xFE000000から0xFFFFFFFFの範囲の拡張チャネルデータ転送 'data_type_code'値を割り当てません。 [RFC2434]で説明されているように、その範囲の拡張チャネルデータ転送 'data_type_code'の値はプライベート使用のために残されます。前述のとおり、IANAへの実際の指示は[SSH-NUMBERS]にあります。
When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF.
パーティがチャネルにこれ以上データを送信しない場合は、SSH_MSG_CHANNEL_EOFを送信する必要があります（SHOULD）。
byte SSH_MSG_CHANNEL_EOF uint32 recipient channel
バイトSSH_MSG_CHANNEL_EOF uint32受信者チャネル
No explicit response is sent to this message. However, the application may send EOF to whatever is at the other end of the channel. Note that the channel remains open after this message, and more data may still be sent in the other direction. This message does not consume window space and can be sent even if no window space is available.
このメッセージには明示的な応答は送信されません。ただし、アプリケーションは、チャネルの反対側にあるものには何でもEOFを送信できます。このメッセージの後もチャネルは開いたままであり、さらに多くのデータがまだ他の方向に送信される可能性があることに注意してください。このメッセージはウィンドウスペースを消費せず、ウィンドウスペースが利用できない場合でも送信できます。
When either party wishes to terminate the channel, it sends SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. The channel is considered closed for a party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then reuse the channel number. A party MAY send SSH_MSG_CHANNEL_CLOSE without having sent or received SSH_MSG_CHANNEL_EOF.
いずれかの当事者がチャネルを終了したい場合、SSH_MSG_CHANNEL_CLOSEを送信します。このメッセージを受信した場合、パーティは、チャネルに対してこのメッセージをすでに送信していない限り、SSH_MSG_CHANNEL_CLOSEを返信する必要があります。チャネルは、SSH_MSG_CHANNEL_CLOSEの送信と受信の両方を行ったときにパーティに対して閉じていると見なされ、パーティはチャネル番号を再利用できます。パーティは、SSH_MSG_CHANNEL_EOFを送受信せずにSSH_MSG_CHANNEL_CLOSEを送信できます（MAY）。
byte SSH_MSG_CHANNEL_CLOSE uint32 recipient channel
バイトSSH_MSG_CHANNEL_CLOSE uint32受信者チャネル
This message does not consume window space and can be sent even if no window space is available.
このメッセージはウィンドウスペースを消費せず、ウィンドウスペースが利用できない場合でも送信できます。
It is RECOMMENDED that all data sent before this message be delivered to the actual destination, if possible.
可能であれば、このメッセージの前に送信されたすべてのデータを実際の宛先に配信することをお勧めします。
Many 'channel type' values have extensions that are specific to that particular 'channel type'. An example is requesting a pty (pseudo terminal) for an interactive session.
多くの「チャネルタイプ」値には、その特定の「チャネルタイプ」に固有の拡張機能があります。例として、対話型セッションのpty（疑似端末）の要求があります。
All channel-specific requests use the following format.
すべてのチャネル固有の要求は、次の形式を使用します。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string request type in US-ASCII characters only
boolean want reply
.... type-specific data follows
If 'want reply' is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.
「返信を希望」がFALSEの場合、リクエストに応答は送信されません。それ以外の場合、受信者はSSH_MSG_CHANNEL_SUCCESS、SSH_MSG_CHANNEL_FAILURE、または要求固有の継続メッセージのいずれかで応答します。要求が認識されないか、チャネルでサポートされていない場合、SSH_MSG_CHANNEL_FAILUREが返されます。
This message does not consume window space and can be sent even if no window space is available. The values of 'request type' are local to each channel type.
このメッセージはウィンドウスペースを消費せず、ウィンドウスペースが利用できない場合でも送信できます。 「リクエストタイプ」の値は、各チャネルタイプに対してローカルです。
The client is allowed to send further messages without waiting for the response to the request.
クライアントは、リクエストへの応答を待たずに、さらにメッセージを送信できます。
'request type' names follow the DNS extensibility naming convention outlined in [SSH-ARCH] and [SSH-NUMBERS].
「要求タイプ」の名前は、[SSH-ARCH]および[SSH-NUMBERS]で概説されているDNS拡張性命名規則に従います。
byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient channel
バイトSSH_MSG_CHANNEL_SUCCESS uint32受信者チャネル
byte SSH_MSG_CHANNEL_FAILURE uint32 recipient channel
バイトSSH_MSG_CHANNEL_FAILURE uint32受信者チャネル
These messages do not consume window space and can be sent even if no window space is available.
これらのメッセージはウィンドウスペースを消費せず、ウィンドウスペースが利用できない場合でも送信できます。
A session is a remote execution of a program. The program may be a shell, an application, a system command, or some built-in subsystem. It may or may not have a tty, and may or may not involve X11 forwarding. Multiple sessions can be active simultaneously.
セッションは、プログラムのリモート実行です。プログラムは、シェル、アプリケーション、システムコマンド、またはいくつかの組み込みサブシステムです。 ttyがある場合とない場合があり、X11転送が含まれる場合と含まれない場合があります。複数のセッションを同時にアクティブにすることができます。
A session is started by sending the following message.
次のメッセージを送信することにより、セッションが開始されます。
byte SSH_MSG_CHANNEL_OPEN string "session" uint32 sender channel uint32 initial window size uint32 maximum packet size
バイトSSH_MSG_CHANNEL_OPEN文字列 "セッション" uint32送信側チャネルuint32初期ウィンドウサイズuint32最大パケットサイズ
Client implementations SHOULD reject any session channel open requests to make it more difficult for a corrupt server to attack the client.
クライアントの実装は、破損したサーバーがクライアントを攻撃するのをより困難にするために、セッションチャネルのオープン要求を拒否する必要があります（SHOULD）。
A pseudo-terminal can be allocated for the session by sending the following message.
次のメッセージを送信することにより、セッションに疑似端末を割り当てることができます。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "pty-req" boolean want_reply string TERM environment variable value (e.g., vt100) uint32 terminal width, characters (e.g., 80) uint32 terminal height, rows (e.g., 24) uint32 terminal width, pixels (e.g., 640) uint32 terminal height, pixels (e.g., 480) string encoded terminal modes
バイトSSH_MSG_CHANNEL_REQUEST uint32受信側チャネル文字列 "pty-req"ブールwant_reply文字列TERM環境変数値（たとえば、vt100）uint32端末の幅、文字（たとえば、80）uint32端末の高さ、行（たとえば、24）uint32端末の幅、ピクセル（たとえば、640）uint32端末の高さ、ピクセル（たとえば、480）文字列エンコードされた端末モード
The 'encoded terminal modes' are described in Section 8. Zero dimension parameters MUST be ignored. The character/row dimensions override the pixel dimensions (when nonzero). Pixel dimensions refer to the drawable area of the window.
「エンコードされた端末モード」については、セクション8で説明します。ゼロ次元パラメーターは無視する必要があります。文字/行の寸法はピクセルの寸法を上書きします（ゼロ以外の場合）。ピクセル寸法は、ウィンドウの描画可能領域を指します。
The dimension parameters are only informational.
寸法パラメータは情報を提供するだけです。
The client SHOULD ignore pty requests.
クライアントはptyリクエストを無視すべきです（SHOULD）。
X11 forwarding may be requested for a session by sending a SSH_MSG_CHANNEL_REQUEST message.
SSH_MSG_CHANNEL_REQUESTメッセージを送信することにより、セッションのX11転送を要求できます。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "x11-req" boolean want reply boolean single connection string x11 authentication protocol string x11 authentication cookie uint32 x11 screen number
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列 "x11-req"ブール値応答を要求ブール値シングル接続文字列x11認証プロトコル文字列x11認証cookie uint32 x11画面番号
It is RECOMMENDED that the 'x11 authentication cookie' that is sent be a fake, random cookie, and that the cookie be checked and replaced by the real cookie when a connection request is received.
送信される「x11認証Cookie」は偽のランダムなCookieであり、接続要求が受信されたときにCookieを確認して実際のCookieに置き換えることをお勧めします。
X11 connection forwarding should stop when the session channel is closed. However, already opened forwardings should not be automatically closed when the session channel is closed.
X11接続の転送は、セッションチャネルが閉じられると停止するはずです。ただし、すでに開かれている転送は、セッションチャネルが閉じられたときに自動的に閉じられるべきではありません。
If 'single connection' is TRUE, only a single connection should be forwarded. No more connections will be forwarded after the first, or after the session channel has been closed.
「単一接続」がTRUEの場合、単一の接続のみが転送されます。最初の接続後、またはセッションチャネルが閉じられた後は、接続は転送されません。
The 'x11 authentication protocol' is the name of the X11 authentication method used, e.g., "MIT-MAGIC-COOKIE-1".
「x11認証プロトコル」は、「MIT-MAGIC-COOKIE-1」など、使用されるX11認証方式の名前です。
The 'x11 authentication cookie' MUST be hexadecimal encoded.
「x11認証Cookie」は16進数でエンコードする必要があります。
The X Protocol is documented in [SCHEIFLER].
Xプロトコルは[SCHEIFLER]で文書化されています。
X11 channels are opened with a channel open request. The resulting channels are independent of the session, and closing the session channel does not close the forwarded X11 channels.
X11チャネルは、チャネルオープン要求で開かれます。結果のチャネルはセッションから独立しており、セッションチャネルを閉じても転送されたX11チャネルは閉じません。
byte SSH_MSG_CHANNEL_OPEN string "x11" uint32 sender channel uint32 initial window size uint32 maximum packet size string originator address (e.g., "192.168.7.38") uint32 originator port
バイトSSH_MSG_CHANNEL_OPEN文字列 "x11" uint32送信側チャネルuint32初期ウィンドウサイズuint32最大パケットサイズ文字列発信元アドレス（例： "192.168.7.38"）uint32発信元ポート
The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
受信者はSSH_MSG_CHANNEL_OPEN_CONFIRMATIONまたはSSH_MSG_CHANNEL_OPEN_FAILUREで応答する必要があります。
Implementations MUST reject any X11 channel open requests if they have not requested X11 forwarding.
実装は、X11転送を要求していない場合、X11チャネルのオープン要求を拒否する必要があります。
Environment variables may be passed to the shell/command to be started later. Uncontrolled setting of environment variables in a privileged process can be a security hazard. It is recommended that implementations either maintain a list of allowable variable names or only set environment variables after the server process has dropped sufficient privileges.
環境変数をシェル/コマンドに渡して、後で起動することができます。特権プロセスでの環境変数の制御されていない設定は、セキュリティ上の問題となる可能性があります。サーバープロセスが十分な特権を削除した後、実装では、許容される変数名のリストを維持するか、環境変数のみを設定することをお勧めします。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "env" boolean want reply string variable name string variable value
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列 "env"ブール値応答文字列変数名文字列変数値
Once the session has been set up, a program is started at the remote end. The program can be a shell, an application program, or a subsystem with a host-independent name. Only one of these requests can succeed per channel.
セッションがセットアップされると、プログラムがリモートエンドで開始されます。プログラムは、シェル、アプリケーションプログラム、またはホストに依存しない名前のサブシステムにすることができます。これらの要求の1つだけがチャネルごとに成功できます。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "shell" boolean want reply
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列 "shell"ブール値の応答を要求
This message will request that the user's default shell (typically defined in /etc/passwd in UNIX systems) be started at the other end.
このメッセージは、ユーザーのデフォルトシェル（通常はUNIXシステムの/ etc / passwdで定義されている）を反対側で起動するように要求します。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exec" boolean want reply string command
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列「exec」ブール値の応答文字列を要求するコマンド
This message will request that the server start the execution of the given command. The 'command' string may contain a path. Normal precautions MUST be taken to prevent the execution of unauthorized commands.
このメッセージは、サーバーが指定されたコマンドの実行を開始することを要求します。 'command'文字列にはパスを含めることができます。不正なコマンドの実行を防ぐために、通常の予防策を講じる必要があります。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string subsystem name
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列「サブシステム」ブール値の応答文字列サブシステム名
This last form executes a predefined subsystem. It is expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish it from arbitrary output generated by shell initialization scripts, etc. This spurious output from the shell may be filtered out either at the server or at the client.
この最後のフォームは、事前定義されたサブシステムを実行します。これらには、一般的なファイル転送メカニズム、および場合によっては他の機能が含まれることが予想されます。実装では、このようなメカニズムをさらに構成することもできます。ユーザーのシェルは通常、サブシステムの実行に使用されるため、サブシステムプロトコルのプロトコルトランザクションの先頭に「マジックCookie」を設定して、シェル初期化スクリプトなどによって生成された任意の出力と区別することをお勧めします。シェルからは、サーバーまたはクライアントのいずれかで除外できます。
The server SHOULD NOT halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel.
シェルまたはプログラムを起動するときに、サーバーはプロトコルスタックの実行を停止してはなりません。これらからのすべての入力と出力は、チャネルまたは暗号化されたトンネルにリダイレクトする必要があります（SHOULD）。
It is RECOMMENDED that the reply to these messages be requested and checked. The client SHOULD ignore these messages.
これらのメッセージへの返信をリクエストして確認することをお勧めします。クライアントはこれらのメッセージを無視すべきです（SHOULD）。
Subsystem names follow the DNS extensibility naming convention outlined in [SSH-NUMBERS].
サブシステム名は、[SSH-NUMBERS]で概説されているDNS拡張性命名規則に従います。
Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr data.
セッションのデータ転送は、SSH_MSG_CHANNEL_DATAおよびSSH_MSG_CHANNEL_EXTENDED_DATAパケットとウィンドウメカニズムを使用して行われます。拡張データ型SSH_EXTENDED_DATA_STDERRがstderrデータに定義されました。
When the window (terminal) size changes on the client side, it MAY send a message to the other side to inform it of the new dimensions.
クライアント側でウィンドウ（端末）のサイズが変更されると、新しい次元を通知するメッセージを反対側に送信する場合があります（MAY）。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "window-change" boolean FALSE uint32 terminal width, columns uint32 terminal height, rows uint32 terminal width, pixels uint32 terminal height, pixels
バイトSSH_MSG_CHANNEL_REQUEST uint32受信側チャネル文字列 "window-change"ブールFALSE uint32端末の幅、列uint32端末の高さ、行uint32端末の幅、ピクセルuint32端末の高さ、ピクセル
A response SHOULD NOT be sent to this message.
このメッセージには応答を送信しないでください。
On many systems, it is possible to determine if a pseudo-terminal is using control-S/control-Q flow control. When flow control is allowed, it is often desirable to do the flow control at the client end to speed up responses to user requests. This is facilitated by the following notification. Initially, the server is responsible for flow control. (Here, again, client means the side originating the session, and server means the other side.)
多くのシステムでは、疑似端末がcontrol-S / control-Qフロー制御を使用しているかどうかを判別できます。フロー制御が許可されている場合、ユーザー要求への応答を高速化するために、クライアント側でフロー制御を行うことが望ましい場合がよくあります。これは、次の通知によって促進されます。最初は、サーバーがフロー制御を担当します。 （ここでも、クライアントはセッションを開始した側を意味し、サーバーは反対側を意味します。）
The message below is used by the server to inform the client when it can or cannot perform flow control (control-S/control-Q processing). If 'client can do' is TRUE, the client is allowed to do flow control using control-S and control-Q. The client MAY ignore this message.
以下のメッセージは、サーバーがクライアントにフロー制御（control-S / control-Q処理）を実行できるかどうかを通知するために使用されます。 「クライアントが実行できる」がTRUEの場合、クライアントはcontrol-Sおよびcontrol-Qを使用してフロー制御を実行できます。クライアントはこのメッセージを無視してもよい（MAY）。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "xon-xoff" boolean FALSE boolean client can do
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列 "xon-xoff"ブールFALSEブールクライアントは実行できます
No response is sent to this message.
このメッセージに対する応答は送信されません。
A signal can be delivered to the remote process/service using the following message. Some systems may not implement signals, in which case they SHOULD ignore this message.
次のメッセージを使用して、リモートプロセス/サービスにシグナルを配信できます。一部のシステムはシグナルを実装しない場合があります。その場合、このメッセージを無視する必要があります。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "signal" boolean FALSE string signal name (without the "SIG" prefix)
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列 "signal"ブールFALSE文字列信号名（ "SIG"接頭辞なし）
'signal name' values will be encoded as discussed in the passage describing SSH_MSG_CHANNEL_REQUEST messages using "exit-signal" in this section.
「シグナル名」の値は、このセクションの「exit-signal」を使用してSSH_MSG_CHANNEL_REQUESTメッセージを説明する節で説明されているようにエンコードされます。
When the command running at the other end terminates, the following message can be sent to return the exit status of the command. Returning the status is RECOMMENDED. No acknowledgement is sent for this message. The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this message.
反対側で実行されているコマンドが終了すると、次のメッセージを送信してコマンドの終了ステータスを返すことができます。ステータスを返すことをお勧めします。このメッセージの確認は送信されません。このメッセージの後、SSH_MSG_CHANNEL_CLOSEでチャネルを閉じる必要があります。
The client MAY ignore these messages.
クライアントはこれらのメッセージを無視してもよい（MAY）。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exit-status" boolean FALSE uint32 exit_status
バイトSSH_MSG_CHANNEL_REQUEST uint32受信者チャネル文字列 "exit-status"ブールFALSE uint32 exit_status
The remote command may also terminate violently due to a signal. Such a condition can be indicated by the following message. A zero 'exit_status' usually means that the command terminated successfully.
リモートコマンドは、信号が原因で激しく終了する場合もあります。このような状態は、次のメッセージで示されます。ゼロの「exit_status」は通常、コマンドが正常に終了したことを意味します。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exit-signal" boolean FALSE string signal name (without the "SIG" prefix) boolean core dumped string error message in ISO-10646 UTF-8 encoding string language tag [RFC3066]
バイトSSH_MSG_CHANNEL_REQUEST uint32受信側チャネル文字列 "exit-signal"ブールFALSE文字列信号名（ "SIG"プレフィックスなし）ブールコアダンプ文字列ISO-10646 UTF-8エンコード文字列言語タグのエラーメッセージ[RFC3066]
The 'signal name' is one of the following (these are from [POSIX]).
「シグナル名」は以下のいずれかです（これらは[POSIX]からのものです）。
ABRT ALRM FPE HUP ILL INT KILL PIPE QUIT SEGV TERM USR1 USR2
ABRT ALRM FPE HUP ILL INT KILL PIPE QUIT SEGV TERM USR1 USR2
Additional 'signal name' values MAY be sent in the format "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular implementer wants (except the "@" sign). However, it is suggested that if a 'configure' script is used, any non-standard 'signal name' values it finds be encoded as "SIG@xyz.config.guess", where "SIG" is the 'signal name' without the "SIG" prefix, and "xyz" is the host type, as determined by "config.guess".
追加の「信号名」の値は、「sig-name @ xyz」の形式で送信できます。「sig-name」と「xyz」は、特定の実装者が必要とするもの（「@」記号を除く）にすることができます。ただし、 'configure'スクリプトを使用する場合、非標準の '信号名'の値は "SIG@xyz.config.guess"としてエンコードすることをお勧めします。ここで、 "SIG"は、 「SIG」プレフィックス、「xyz」は「config.guess」によって決定されるホストタイプです。
The 'error message' contains an additional textual explanation of the error message. The message may consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. The client software MAY display this message to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH].
「エラーメッセージ」には、エラーメッセージの追加のテキスト説明が含まれています。メッセージは、CRLF（改行-改行）のペアで区切られた複数の行で構成される場合があります。クライアントソフトウェアは、このメッセージをユーザーに表示する場合があります。これが行われる場合、クライアントソフトウェアは[SSH-ARCH]で説明されている予防措置を取る必要があります。
A party need not explicitly request forwardings from its own end to the other direction. However, if it wishes that connections to a port on the other side be forwarded to the local side, it must explicitly request this.
パーティは、自分のエンドから他の方向への転送を明示的に要求する必要はありません。ただし、反対側のポートへの接続をローカル側に転送したい場合は、明示的に要求する必要があります。
byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want reply string address to bind (e.g., "0.0.0.0") uint32 port number to bind
バイトSSH_MSG_GLOBAL_REQUEST文字列 "tcpip-forward"ブール値にバインドする応答文字列アドレス（例： "0.0.0.0"）バインドするuint32ポート番号
The 'address to bind' and 'port number to bind' specify the IP address (or domain name) and port on which connections for forwarding are to be accepted. Some strings used for 'address to bind' have special-case semantics.
「バインドするアドレス」と「バインドするポート番号」は、転送用の接続を受け入れるIPアドレス（またはドメイン名）とポートを指定します。 「バインドするアドレス」に使用される一部の文字列には、特殊なケースのセマンティクスがあります。
o "" means that connections are to be accepted on all protocol families supported by the SSH implementation.
o 「」は、SSH実装でサポートされているすべてのプロトコルファミリで接続が受け入れられることを意味します。
o "0.0.0.0" means to listen on all IPv4 addresses.
o 「0.0.0.0」は、すべてのIPv4アドレスでリッスンすることを意味します。
o "::" means to listen on all IPv6 addresses.
o 「::」は、すべてのIPv6アドレスでリッスンすることを意味します。
o "localhost" means to listen on all protocol families supported by the SSH implementation on loopback addresses only ([RFC3330] and [RFC3513]).
o 「localhost」は、ループバックアドレス（[RFC3330]および[RFC3513]）のSSH実装でサポートされているすべてのプロトコルファミリをリッスンすることを意味します。
o "127.0.0.1" and "::1" indicate listening on the loopback interfaces for IPv4 and IPv6, respectively.
o "127.0.0.1"と ":: 1"は、それぞれIPv4とIPv6のループバックインターフェイスでリッスンすることを示します。
Note that the client can still filter connections based on information passed in the open request.
クライアントはオープン要求で渡された情報に基づいて接続をフィルタリングできることに注意してください。
Implementations should only allow forwarding privileged ports if the user has been authenticated as a privileged user.
実装では、ユーザーが特権ユーザーとして認証されている場合にのみ特権ポートの転送を許可する必要があります。
Client implementations SHOULD reject these messages; they are normally only sent by the client.
クライアントの実装はこれらのメッセージを拒否する必要があります。通常はクライアントからのみ送信されます。
If a client passes 0 as port number to bind and has 'want reply' as TRUE, then the server allocates the next available unprivileged port number and replies with the following message; otherwise, there is no response-specific data.
クライアントがバインドするポート番号として0を渡し、「返信したい」がTRUEである場合、サーバーは次に使用可能な非特権ポート番号を割り当て、次のメッセージで応答します。それ以外の場合、応答固有のデータはありません。
byte SSH_MSG_REQUEST_SUCCESS uint32 port that was bound on the server
サーバーにバインドされたバイトSSH_MSG_REQUEST_SUCCESS uint32ポート
A port forwarding can be canceled with the following message. Note that channel open requests may be received until a reply to this message is received.
次のメッセージでポート転送をキャンセルできます。このメッセージへの応答が受信されるまで、チャネルオープン要求が受信される場合があることに注意してください。
byte SSH_MSG_GLOBAL_REQUEST string "cancel-tcpip-forward" boolean want reply string address_to_bind (e.g., "127.0.0.1") uint32 port number to bind
バイトSSH_MSG_GLOBAL_REQUEST文字列 "cancel-tcpip-forward"ブール値の返信文字列address_to_bind（例： "127.0.0.1"）バインドするuint32ポート番号
Client implementations SHOULD reject these messages; they are normally only sent by the client.
クライアントの実装はこれらのメッセージを拒否する必要があります。通常はクライアントからのみ送信されます。
When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side.
リモート転送が要求されたポートに接続が来ると、チャネルを開いてポートを反対側に転送します。
byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string address that was connected uint32 port that was connected string originator IP address uint32 originator port
バイトSSH_MSG_CHANNEL_OPEN文字列 "forwarded-tcpip" uint32送信者チャネルuint32初期ウィンドウサイズuint32最大パケットサイズ文字列接続されたアドレスuint32ポート接続された文字列発信元IPアドレスuint32発信者ポート
Implementations MUST reject these messages unless they have previously requested a remote TCP/IP port forwarding with the given port number.
実装は、指定されたポート番号でリモートTCP / IPポート転送を以前に要求していない限り、これらのメッセージを拒否する必要があります。
When a connection comes to a locally forwarded TCP/IP port, the following packet is sent to the other side. Note that these messages MAY also be sent for ports for which no forwarding has been explicitly requested. The receiving side must decide whether to allow the forwarding.
接続がローカルに転送されたTCP / IPポートに到達すると、次のパケットが反対側に送信されます。これらのメッセージは、転送が明示的に要求されていないポートに対しても送信される場合があることに注意してください。受信側は、転送を許可するかどうかを決定する必要があります。
byte SSH_MSG_CHANNEL_OPEN string "direct-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string host to connect uint32 port to connect string originator IP address uint32 originator port
バイトSSH_MSG_CHANNEL_OPEN文字列 "direct-tcpip" uint32送信側チャネルuint32初期ウィンドウサイズuint32最大パケットサイズ文字列host to connect uint32 port to connect string originator IP address uint32 originator port
The 'host to connect' and 'port to connect' specify the TCP/IP host and port where the recipient should connect the channel. The 'host to connect' may be either a domain name or a numeric IP address.
「接続するホスト」と「接続するポート」は、受信者がチャネルに接続する必要があるTCP / IPホストとポートを指定します。 「接続するホスト」は、ドメイン名または数値のIPアドレスのいずれかです。
The 'originator IP address' is the numeric IP address of the machine from where the connection request originates, and the 'originator port' is the port on the host from where the connection originated.
「発信元IPアドレス」は、接続要求が発信されたマシンの数値IPアドレスであり、「発信元ポート」は、接続が発信されたホスト上のポートです。
Forwarded TCP/IP channels are independent of any sessions, and closing a session channel does not in any way imply that forwarded connections should be closed.
転送されたTCP / IPチャネルは、どのセッションからも独立しており、セッションチャネルを閉じても、転送された接続を閉じる必要があることを意味するものではありません。
Client implementations SHOULD reject direct TCP/IP open requests for security reasons.
クライアントの実装は、セキュリティ上の理由から、直接TCP / IPオープン要求を拒否する必要があります（SHOULD）。
All 'encoded terminal modes' (as passed in a pty request) are encoded into a byte stream. It is intended that the coding be portable across different environments. The stream consists of opcode-argument pairs wherein the opcode is a byte value. Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined, and cause parsing to stop (they should only be used after any other data). The stream is terminated by opcode TTY_OP_END (0x00).
すべての「エンコードされた端末モード」（ptyリクエストで渡される）は、バイトストリームにエンコードされます。コーディングは異なる環境間で移植可能であることを意図しています。ストリームは、オペコードとバイトのペアで構成され、オペコードはバイト値です。オペコード1から159には、単一のuint32引数があります。オペコード160〜255はまだ定義されていないため、解析が停止します（他のデータの後にのみ使用する必要があります）。ストリームは、オペコードTTY_OP_END（0x00）で終了します。
The client SHOULD put any modes it knows about in the stream, and the server MAY ignore any modes it does not know about. This allows some degree of machine-independence, at least between systems that use a POSIX-like tty interface. The protocol can support other systems as well, but the client may need to fill reasonable values for a number of parameters so the server pty gets set to a reasonable mode (the server leaves all unspecified mode bits in their default values, and only some combinations make sense).
クライアントはそれが知っているモードをストリームに入れるべきであり（SHOULD）、サーバーはそれが知らないモードを無視してもよいです（MAY）。これにより、少なくともPOSIXのようなttyインターフェースを使用するシステム間で、ある程度のマシンに依存しないようにすることができます。プロトコルは他のシステムもサポートできますが、サーバーのptyが適切なモードに設定されるように、クライアントはいくつかのパラメーターに適切な値を入力する必要がある場合があります（サーバーはすべての未指定モードビットをデフォルト値に残し、一部の組み合わせのみを残します）意味があります）。
The naming of opcode values mostly follows the POSIX terminal mode flags. The following opcode values have been defined. Note that the values given below are in decimal format for readability, but they are actually byte values.
オペコード値の命名は、主にPOSIX端末モードフラグに従います。次のオペコード値が定義されています。下記の値は読みやすいように10進数形式ですが、実際にはバイト値です。
opcode mnemonic description
------ -------- -----------
0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly
for the other characters. Not all of these
characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on
POSIX systems).
3 VERASE Erase the character to left of the cursor.
4 VKILL Kill the current input line.
5 VEOF End-of-file character (sends EOF from the
terminal).
6 VEOL End-of-line character in addition to
carriage return and/or linefeed.
7 VEOL2 Additional end-of-line character.
8 VSTART Continues paused output (normally
control-Q).
9 VSTOP Pauses output (normally control-S).
10 VSUSP Suspends the current program.
11 VDSUSP Another suspend character.
12 VREPRINT Reprints the current input line. 13 VWERASE Erases a word left of cursor. 14 VLNEXT Enter the next character typed literally, even if it is a special character 15 VFLUSH Character to flush output. 16 VSWTCH Switch to a different shell layer. 17 VSTATUS Prints system status line (load, command, pid, etc). 18 VDISCARD Toggles the flushing of terminal output. 30 IGNPAR The ignore parity flag. The parameter SHOULD be 0 if this flag is FALSE, and 1 if it is TRUE. 31 PARMRK Mark parity and framing errors. 32 INPCK Enable checking of parity errors. 33 ISTRIP Strip 8th bit off characters. 34 INLCR Map NL into CR on input. 35 IGNCR Ignore CR on input. 36 ICRNL Map CR to NL on input. 37 IUCLC Translate uppercase characters to lowercase. 38 IXON Enable output flow control. 39 IXANY Any char will restart after stop. 40 IXOFF Enable input flow control. 41 IMAXBEL Ring bell on input queue full. 50 ISIG Enable signals INTR, QUIT, [D]SUSP. 51 ICANON Canonicalize input lines. 52 XCASE Enable input and output of uppercase characters by preceding their lowercase equivalents with "\". 53 ECHO Enable echoing. 54 ECHOE Visually erase chars. 55 ECHOK Kill character discards current line. 56 ECHONL Echo NL even if ECHO is off. 57 NOFLSH Don't flush after interrupt. 58 TOSTOP Stop background jobs from output. 59 IEXTEN Enable extensions. 60 ECHOCTL Echo control characters as ^(Char). 61 ECHOKE Visual erase for line kill. 62 PENDIN Retype pending input. 70 OPOST Enable output processing. 71 OLCUC Convert lowercase to uppercase. 72 ONLCR Map NL to CR-NL. 73 OCRNL Translate carriage return to newline (output). 74 ONOCR Translate newline to carriage return-newline (output). 75 ONLRET Newline performs a carriage return (output).
12 VREPRINT現在の入力行を再印刷します。 13 VWERASEカーソルの左の単語を消去します。 14 VLNEXT特殊文字であっても、文字どおりに入力された次の文字を入力します。15 VFLUSH出力をフラッシュする文字。 16 VSWTCH別のシェルレイヤーに切り替えます。 17 VSTATUSシステムステータス行（ロード、コマンド、pidなど）を出力します。 18 VDISCARD端末出力のフラッシュを切り替えます。 30 IGNPARパリティ無視フラグ。このフラグがFALSEの場合、パラメーターは0であり、TRUEの場合は1です。 31 PARMRKマークパリティおよびフレーミングエラー。 32 INPCKパリティエラーのチェックを有効にします。 33 ISTRIP 8番目のビットオフ文字。 34 INLCR入力時にNLをCRにマップします。 35 IGNCR入力時にCRを無視します。 36 ICRNL入力時にCRをNLにマップします。 37 IUCLC大文字を小文字に変換します。 38 IXON出力フロー制御を有効にします。 39 IXANY任意の文字は停止後に再起動します。 40 IXOFF入力フロー制御を有効にします。 41 IMAXBEL入力キューの呼び出しベルがいっぱいです。 50 ISIGイネーブル信号INTR、QUIT、[D] SUSP。 51 ICANON入力行を正規化します。 52 XCASE同等の小文字の前に「\」を付けることにより、大文字の入力と出力を有効にします。 53 ECHOエコーを有効にします。 54 ECHOE文字を視覚的に消去します。 55 ECHOKキル文字は現在の行を破棄します。 ECHOがオフの場合でも、56 ECHONL Echo NL。 57 NOFLSH割り込み後にフラッシュしません。 58 TOSTOPバックグラウンドジョブの出力を停止します。 59 IEXTEN拡張機能を有効にします。 60 ECHOCTL ^（Char）としてのエコー制御文字。 61 ECHOKE目を消すための行消去。 62 PENDIN保留中の入力を再入力します。 70 OPOST出力処理を有効にします。 71 OLCUC小文字を大文字に変換します。 72 ONLCR NLをCR-NLにマップします。 73 OCRNLキャリッジリターンを改行（出力）に変換します。 74 ONOCR改行を復帰改行（出力）に変換します。 75 ONLRET改行は、キャリッジリターン（出力）を実行します。
90 CS7 7 bit mode. 91 CS8 8 bit mode. 92 PARENB Parity enable. 93 PARODD Odd parity, else even.
90 CS7 7ビットモード。 91 CS8 8ビットモード。 92 PARENBパリティ有効。 93 PARODD奇数パリティ、それ以外の場合。
128 TTY_OP_ISPEED Specifies the input baud rate in bits per second. 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second.
128 TTY_OP_ISPEED入力ボーレートをビット/秒で指定します。 129 TTY_OP_OSPEED出力ボーレートをビット/秒で指定します。
The following is a summary of messages and their associated message number.
以下は、メッセージとそれに関連するメッセージ番号の要約です。
SSH_MSG_GLOBAL_REQUEST 80 SSH_MSG_REQUEST_SUCCESS 81 SSH_MSG_REQUEST_FAILURE 82 SSH_MSG_CHANNEL_OPEN 90 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 SSH_MSG_CHANNEL_OPEN_FAILURE 92 SSH_MSG_CHANNEL_WINDOW_ADJUST 93 SSH_MSG_CHANNEL_DATA 94 SSH_MSG_CHANNEL_EXTENDED_DATA 95 SSH_MSG_CHANNEL_EOF 96 SSH_MSG_CHANNEL_CLOSE 97 SSH_MSG_CHANNEL_REQUEST 98 SSH_MSG_CHANNEL_SUCCESS 99 SSH_MSG_CHANNEL_FAILURE 100
SSH_MSG_GLOBAL_REQUEST 80 SSH_MSG_REQUEST_SUCCESS 81 SSH_MSG_REQUEST_FAILURE 82 SSH_MSG_CHANNEL_OPEN 90 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 SSH_MSG_CHANNEL_OPEN_FAILURE 92 SSH_MSG_CHANNEL_WINDOW_ADJUST 93 SSH_MSG_CHANNEL_DATA 94 SSH_MSG_CHANNEL_EXTENDED_DATA 95 SSH_MSG_CHANNEL_EOF 96 SSH_MSG_CHANNEL_CLOSE 97 SSH_MSG_CHANNEL_REQUEST 98 SSH_MSG_CHANNEL_SUCCESS 99 SSH_MSG_CHANNEL_FAILURE 100
This document is part of a set. The IANA considerations for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and this document, are detailed in [SSH-NUMBERS].
このドキュメントはセットの一部です。 [SSH-ARCH]、[SSH-TRANS]、[SSH-USERAUTH]、およびこのドキュメントで定義されているSSHプロトコルに関するIANAの考慮事項は、[SSH-NUMBERS]で詳しく説明されています。
This protocol is assumed to run on top of a secure, authenticated transport. User authentication and protection against network-level attacks are assumed to be provided by the underlying protocols.
このプロトコルは、安全で認証されたトランスポート上で実行されると想定されています。ユーザー認証とネットワークレベルの攻撃に対する保護は、基盤となるプロトコルによって提供されると想定されています。
Full security considerations for this protocol are provided in [SSH-ARCH]. Specific to this document, it is RECOMMENDED that implementations disable all the potentially dangerous features (e.g., agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host key has changed without notice or explanation.
このプロトコルの完全なセキュリティの考慮事項は、[SSH-ARCH]で提供されています。このドキュメントに固有であり、ホストキーが予告または説明なしに変更された場合、実装はすべての潜在的に危険な機能（エージェント転送、X11転送、TCP / IP転送など）を無効にすることをお勧めします。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年1月。
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANS] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、2006年1月。
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS] Lehtinen、S。およびC. Lonvick、編、「Secure Shell（SSH）Protocol Assigned Numbers」、RFC 4250、2006年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、「Special-Use IPv4 Addresses」、RFC 3330、2002年9月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, February 1992.
[SCHEIFLER] Scheifler、R。、「X Window System：The Complete Reference to Xlib、X Protocol、Icccm、Xlfd、3rd edition。」、Digital Press ISBN 1555580882、1992年2月。
[POSIX] ISO/IEC, 9945-1., "Information technology -- Portable Operating System Interface (POSIX)-Part 1: System Application Program Interface (API) C Language", ANSI/ IEE Std 1003.1, July 1996.
[POSIX] ISO / IEC、9945-1。、 "Information technology-Portable Operating System Interface（POSIX）-Part 1：System Application Program Interface（API）C Language"、ANSI / IEE Std 1003.1、July 1996。
Authors' Addresses
著者のアドレス
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinkiフィンランド
EMail: ylo@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
Chris Lonvick（編集者）Cisco Systems、Inc. 12515 Research Blvd.オースティン78759アメリカ
EMail: clonvick@cisco.com
Trademark Notice
商標に関する通知
"ssh" is a registered trademark in the United States and/or other countries.
「ssh」は、米国およびその他の国における登録商標です。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
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.
このドキュメントは、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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。