セキュアシェル（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トランスポート層およびユーザー認証プロトコルの上で実行するように設計されています。
Ylonen & Lonvick Standards Track [Page 1] RFC 4254 SSH Connection Protocol January 2006 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
1.はじめに............................................... ..... 2
2.貢献者............................................... ..... 3
3.このドキュメントで使用されている表記法...........................3
4.グローバルリクエスト.............................................4
5.チャネルメカニズム...............................................5
5.1.チャネルを開く.......................................... 5
5.2.データ転送.............................................. 7
5.3.チャネルを閉じる.......................................... 9
5.4.チャネル固有のリクエスト....................................9
6.インタラクティブセッション.......................................10
6.1.セッションを開く............................................10
6.2.疑似端末の要求.............................. 11
6.3. X11転送............................................ 11
6.3.1. X11転送の要求.......................... 11
6.3.2. X11チャネル.........................................12
6.4.環境変数の受け渡し.............................. 12
6.5.シェルまたはコマンドの開始..................................13
6.6.セッションデータ転送..................................... 14
6.7.ウィンドウの寸法変更メッセージ........................... 14
6.8.ローカルフロー制御........................................ 14
6.9信号.........................................................15
6.10.終了ステータスを返す.......................................15
7. TCP / IPポート転送......................................... 16
7.1.ポート転送の要求................................ 16
7.2. TCP / IP転送チャネル................................ 18
8.端末モードのエンコーディング.....................................19
9.メッセージ番号の概要..................................... 21
10. IANAの考慮事項........................................... 21
11.セキュリティに関する考慮事項....................................21
12.参考資料........................................................22
12.1.規範的な参考資料..................................... 22
12.2.有益な参照................................... 22
著者のアドレス............................................... .23
商標に関する通知...................................................23
1. Introduction
1.はじめに
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」です。
Ylonen & Lonvick Standards Track [Page 2] RFC 4254 SSH Connection Protocol January 2006 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]を読んだ後にのみ読む必要があります。 このドキュメントでは、アーキテクチャドキュメントの用語と表記法を自由に使用し、参照や詳細な説明はありません。
2. Contributors
2.貢献者
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 サーリネン（ユヴァスキュラ大学）。 ダレンモファットは、この一連のドキュメントの最初の編集者であり、非常に大きな貢献もしました。
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.
このドキュメントの開発には、長年にわたって多くの人々が貢献してくれました。 認められるべき人には、マット・アンダーソン、ベン・ハリス、ビル・ソマーフェルト、ブレント・マクルーア、ニールス・モラー、ダミアン・ミラー、デレク・フォーカス、フランク・カザック、ヘイッキ・ノイシャイネン、ジェイコブ・シュリター、ジェフ・ヴァン・ダイク、ジェフリー・アルトマン、ジェフリー・ハッツェルマン、ジョン・ブライト、ジョセフ ガルブレイス、ケンホーンスタイン、マーカスフリードル、マーティンフォーセン、ニコラスウィリアムズ、ニールスプロボス、ペリーメッツガー、ピーターグトマン、サイモンジョセフソン、サイモンテイサム、ウェイダイ、デニスバイダー、マウス、デアマウス、河野忠義。 ここに彼らの名前をリストすることは、彼らがこの文書を支持することを意味するのではなく、彼らがそれに貢献したことを意味します。
3. Conventions Used in This Document
3.このドキュメントで使用される規則
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
byte SSH_MSG_CHANNEL_DATA
uint32 受信者チャネル
string データ
Ylonen & Lonvick Standards Track [Page 3] RFC 4254 SSH Connection Protocol January 2006 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」です。
4. Global Requests
4.グローバルなリクエスト
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
byte SSH_MSG_GLOBAL_REQUEST
string US-ASCIIのみのリクエスト名
boolean 返信が欲しい
.... リクエスト固有のデータが続きます
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
byte SSH_MSG_REQUEST_SUCCESS
.... 応答固有のデータ
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
byte 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への応答を、対応する要求メッセージと同じ順序で送信する必要があります。 チャネル要求の場合、同じチャネルに関連する応答も正しい順序で応答する必要があります。 ただし、個別のチャネルに対するチャネル要求は、順不同で応答される場合があります。
Ylonen & Lonvick Standards Track [Page 4] RFC 4254 SSH Connection Protocol January 2006 5. Channel Mechanism
5.チャネルメカニズム
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.
チャネルはフロー制御されます。 ウィンドウスペースが利用可能であることを示すメッセージが受信されるまで、チャネルにデータを送信できません。
5.1. Opening a Channel
5.1。 チャンネルを開く
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
byte SSH_MSG_CHANNEL_OPEN
string US-ASCIIのみのチャネルタイプ
uint32 送信者チャネル
uint32 初期ウィンドウサイズ
uint32 最大パケットサイズ
.... チャネルタイプ固有のデータが続きます
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で応答します。
Ylonen & Lonvick Standards Track [Page 5]
RFC 4254 SSH Connection Protocol January 2006
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
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 受信者チャネル
uint32 送信者チャネル
uint32 初期ウィンドウサイズ
uint32 最大パケットサイズ
.... チャネルタイプ固有のデータが続きます
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]
byte SSH_MSG_CHANNEL_OPEN_FAILURE
uint32 受信者チャネル
uint32 理由コード
string ISO-10646 UTF-8エンコーディングの記述[RFC3629]
string 言語タグ[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つの部分に分割され、次の規則によって管理されます。
Ylonen & Lonvick Standards Track [Page 6]
RFC 4254 SSH Connection Protocol January 2006
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で始まる範囲に制限や提案はありません。 この範囲で使用されるものの相互運用性は期待されていません。 基本的に、それは実験用です。
5.2. Data Transfer
5.2。 データ転送
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
byte 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
byte SSH_MSG_CHANNEL_DATA
uint32 受信者チャネル
string データ
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）。
Ylonen & Lonvick Standards Track [Page 7] RFC 4254 SSH Connection Protocol January 2006 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
byte SSH_MSG_CHANNEL_EXTENDED_DATA
uint32 受信者チャネル
uint32 data_type_code
string データ
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]にあります。
Ylonen & Lonvick Standards Track [Page 8] RFC 4254 SSH Connection Protocol January 2006 5.3. Closing a Channel
5.3。 チャネルを閉じる
When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF.
パーティーがチャネルにこれ以上データを送信しない場合、それはすべきです SSH_MSG_CHANNEL_EOFを送信します。
byte SSH_MSG_CHANNEL_EOF
uint32 recipient channel
byte 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
byte 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.
可能であれば、このメッセージの前に送信されたすべてのデータを実際の宛先に配信することをお勧めします。
5.4. Channel-Specific Requests
5.4。 チャネル固有のリクエスト
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string US-ASCII文字のみのリクエストタイプ
boolean 返信が欲しい
.... タイプ固有のデータが続きます
Ylonen & Lonvick Standards Track [Page 9] RFC 4254 SSH Connection Protocol January 2006 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
byte SSH_MSG_CHANNEL_SUCCESS
uint32 受信者チャネル
byte SSH_MSG_CHANNEL_FAILURE
uint32 recipient channel
byte SSH_MSG_CHANNEL_FAILURE
uint32 受信者チャネル
These messages do not consume window space and can be sent even if no window space is available.
これらのメッセージはウィンドウスペースを消費せず、使用可能なウィンドウスペースがない場合でも送信できます。
6. Interactive Sessions
6.インタラクティブセッション
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転送が含まれる場合と含まれない場合があります。 複数のセッションを同時にアクティブにすることができます。
6.1. Opening a Session
6.1。 セッションを開く
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
byte SSH_MSG_CHANNEL_OPEN
string "セッション"
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）。
Ylonen & Lonvick Standards Track [Page 10] RFC 4254 SSH Connection Protocol January 2006 6.2. Requesting a Pseudo-Terminal
6.2。 疑似端末のリクエスト
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "pty-req"
boolean want_reply
string TERM環境変数の値（vt100など）
uint32 端末の幅、文字（80など）
uint32 端末高さ、行（例えば、24）
uint32 端末の幅、ピクセル（640など）
uint32 端末の高さ、ピクセル（例：480）
string エンコードされた端末モード
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）。
6.3. X11 Forwarding
6.3。 X11転送
6.3.1. Requesting X11 Forwarding
6.3.1。 X11転送の要求
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "x11-req"
boolean 返信が欲しい
boolean 単一接続
string x11認証プロトコル
string 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接続の転送は、セッションチャネルが閉じられると停止するはずです。 ただし、すでに開かれている転送は、セッションチャネルが閉じられたときに自動的に閉じられるべきではありません。
Ylonen & Lonvick Standards Track [Page 11] RFC 4254 SSH Connection Protocol January 2006 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]で文書化されています。
6.3.2. X11 Channels
6.3.2。 X11チャネル
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
byte SSH_MSG_CHANNEL_OPEN
string "x11"
uint32 送信者チャネル
uint32 初期ウィンドウサイズ
uint32 最大パケットサイズ
string 発信元アドレス（例：「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チャネルのオープン要求を拒否する必要があります。
6.4. Environment Variable Passing
6.4。 環境変数の受け渡し
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "env"
boolean 返信が欲しい
string 変数名
string 変数値
Ylonen & Lonvick Standards Track [Page 12] RFC 4254 SSH Connection Protocol January 2006 6.5. Starting a Shell or a Command
6.5。 シェルまたはコマンドの開始
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "shell"
boolean 返信が欲しい
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "exec"
boolean 返信が欲しい
string コマンド
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "subsystem"
boolean 返信が欲しい
string サブシステム名
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.
これらのメッセージへの返信をリクエストして確認することをお勧めします。 クライアントはこれらのメッセージを無視すべきです。
Ylonen & Lonvick Standards Track [Page 13] RFC 4254 SSH Connection Protocol January 2006 Subsystem names follow the DNS extensibility naming convention outlined in [SSH-NUMBERS].
サブシステム名は、[SSH-NUMBERS]で概説されているDNS拡張性命名規則に従います。
6.6. Session Data Transfer
6.6。 セッションデータ転送
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データに定義されました。
6.7. Window Dimension Change Message
6.7。 ウィンドウの寸法変更メッセージ
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "window-change"
boolean 偽
uint32 ターミナルの幅、列
uint32 ターミナルの高さ、行
uint32 端末の幅、ピクセル
uint32 端末の高さ、ピクセル
A response SHOULD NOT be sent to this message.
このメッセージには応答を送信すべきではありません（SHOULD NOT）。
6.8. Local Flow Control
6.8。 ローカルフロー制御
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "xon-xoff"
boolean 偽
boolean クライアントができる
No response is sent to this message.
このメッセージに対する応答は送信されません。
Ylonen & Lonvick Standards Track [Page 14] RFC 4254 SSH Connection Protocol January 2006 6.9. Signals
6.9 信号
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.
次のメッセージを使用して、リモートプロセス/サービスにシグナルを配信できます。 一部のシステムはシグナルを実装しない場合があります。その場合、このメッセージを無視する必要があります（SHOULD）。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "signal"
boolean FALSE
string signal name (without the "SIG" prefix)
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "signal"
boolean 偽
string シグナル名（ "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メッセージを説明する節で説明されているようにエンコードされます。
6.10. Returning Exit Status
6.10。 終了ステータスを返す
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "exit-status"
boolean 偽
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]
byte SSH_MSG_CHANNEL_REQUEST
uint32 受信者チャネル
string "exit-signal"
boolean 偽
string シグナル名（ "SIG"接頭辞なし）
boolean コアダンプ
string ISO-10646 UTF-8エンコーディングのエラーメッセージ
string 言語タグ[RFC3066]
Ylonen & Lonvick Standards Track [Page 15] RFC 4254 SSH Connection Protocol January 2006 The 'signal name' is one of the following (these are from [POSIX]).
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]で説明されている予防措置を取る必要があります。
7. TCP/IP Port Forwarding
7. TCP / IPポート転送
7.1. Requesting Port Forwarding
7.1。 ポート転送の要求
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
byte SSH_MSG_GLOBAL_REQUEST
string "tcpip-forward"
boolean 返信が欲しい
string バインドするアドレス（例： "0.0.0.0"）
uint32 バインドするポート番号
Ylonen & Lonvick Standards Track [Page 16] RFC 4254 SSH Connection Protocol January 2006 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として「want reply」を持っている場合、サーバーは次に利用可能な非特権ポート番号を割り当て、次のメッセージで応答します。 それ以外の場合、応答固有のデータはありません。
byte SSH_MSG_REQUEST_SUCCESS
uint32 port that was bound on the server
byte 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
byte SSH_MSG_GLOBAL_REQUEST
string "cancel-tcpip-forward"
boolean 返信が欲しい
string address_to_bind（例： "127.0.0.1"）
uint32 バインドするポート番号
Client implementations SHOULD reject these messages; they are normally only sent by the client.
クライアント実装はこれらのメッセージを拒否する必要があります。 通常はクライアントからのみ送信されます。
Ylonen & Lonvick Standards Track [Page 17] RFC 4254 SSH Connection Protocol January 2006 7.2. TCP/IP Forwarding Channels
7.2。 TCP / IP転送チャネル
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
byte SSH_MSG_CHANNEL_OPEN
string "forwarded-tcpip"
uint32 送信者チャネル
uint32 初期ウィンドウサイズ
uint32 最大パケットサイズ
string 接続されたアドレス
uint32 接続されたポート
string 発信元の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
byte SSH_MSG_CHANNEL_OPEN
string "direct-tcpip"
uint32 送信者チャネル
uint32 初期ウィンドウサイズ
uint32 最大パケットサイズ
string 接続するホスト
uint32 接続するポート
string 発信元のIPアドレス
uint32 発信元ポート
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チャネルは、どのセッションからも独立しており、セッションチャネルを閉じても、転送された接続を閉じる必要があることを意味するものではありません。
Ylonen & Lonvick Standards Track [Page 18] RFC 4254 SSH Connection Protocol January 2006 Client implementations SHOULD reject direct TCP/IP open requests for security reasons.
クライアントの実装は、セキュリティ上の理由から、直接TCP / IPオープン要求を拒否する必要があります（SHOULD）。
8. Encoding of Terminal Modes
8.端末モードのエンコーディング
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リクエストで渡される）は、バイトストリームにエンコードされます。 コーディングは異なる環境間で移植可能であることを意図しています。 ストリームはopcodeと引数のペアで構成され、opcodeはバイト値です。 オペコード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.
Ylonen & Lonvick Standards Track [Page 19]
RFC 4254 SSH Connection Protocol January 2006
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).
Ylonen & Lonvick Standards Track [Page 20]
RFC 4254 SSH Connection Protocol January 2006
90 CS7 7 bit mode.
91 CS8 8 bit mode.
92 PARENB Parity enable.
93 PARODD Odd parity, else even.
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.
オペコード ニモニック 解説
------ -------- -----------
0 TTY_OP_END オプションの終わりを示します。
1 VINTR 割り込み文字。 ない場合は255。
他の文字についても同様です。
これらの文字のすべてがすべてのシステムで
サポートされているわけではありません。
2 VQUIT 終了文字（POSIXシステムではSIGQUITシグナルを送信します）。
3 VERASE カーソルの左側の文字を削除します。
4 VKILL 現在の入力行を削除します。
5 VEOF ファイルの終わり文字（端末からEOFを送信）。
6 VEOL 改行や改行に加えて行末文字。
7 VEOL2 追加の行末文字。
8 VSTART 一時停止した出力を継続します（通常はcontrol-Q）。
9 VSTOP 出力を一時停止します（通常はcontrol-S）。
10 VSUSP 現在のプログラムを一時停止します。
11 VDSUSP 別の中断文字。
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 キルキャラクターは現在の行を破棄します。
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ビットモード。
91 CS8 8ビットモード。
92 PARENB パリティを有効にします。
93 PARODD 奇数パリティ、それ以外。
128 TTY_OP_ISPEED 入力ボーレートをビット/秒で指定します。
129 TTY_OP_OSPEED 出力のボーレートをビット/秒で指定します。
9. Summary of Message Numbers
9.メッセージ番号の要約
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
10. IANA Considerations
10. IANAに関する考慮事項
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]で詳しく説明されています。
11. Security Considerations
11.セキュリティに関する考慮事項
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転送）を無効にすることをお勧めします。
Ylonen & Lonvick Standards Track [Page 21] RFC 4254 SSH Connection Protocol January 2006 12. References
12.リファレンス
12.1. Normative References
12.1。 規範的な参考文献
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253, January
2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Assigned Numbers", RFC 4250, January
2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
12.2. Informative References
12.2。 参考情報
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version
6 (IPv6) Addressing Architecture", RFC 3513, April
2003.
[SCHEIFLER] Scheifler, R., "X Window System : The Complete
Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
edition.", Digital Press ISBN 1555580882, February
1992.
Ylonen & Lonvick Standards Track [Page 22]
RFC 4254 SSH Connection Protocol January 2006
[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
EMail: ylo@ssh.com
Chris Lonvick (editor)
Cisco Systems, Inc.
12515 Research Blvd.
Austin 78759
USA
EMail: clonvick@cisco.com
Trademark Notice
"ssh" is a registered trademark in the United States and/or other
countries.
Ylonen & Lonvick Standards Track [Page 23]
RFC 4254 SSH Connection Protocol 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).
Ylonen & Lonvick Standards Track [Page 24]