セキュアシェル(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]