Secure Shell(SSH)トランスポート層プロトコル

英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。

日本語訳

Network Working Group                                          T. Ylonen
Request for Comments: 4253              SSH Communications Security Corp
Category: Standards Track                                C. Lonvick, Ed.
                                                     Cisco Systems, Inc.
                                                            January 2006


            The Secure Shell (SSH) Transport Layer Protocol

Secure Shell(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

概要


   The 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 transport layer protocol, which
   typically runs on top of TCP/IP.  The protocol can be used as a basis
   for a number of secure network services.  It provides strong
   encryption, server authentication, and integrity protection.  It may
   also provide compression.

このドキュメントでは、通常はTCP / IPの上で実行されるSSHトランスポート層プロトコルについて説明します。 このプロトコルは、多くの安全なネットワークサービスの基盤として使用できます。 強力な暗号化、サーバー認証、および整合性保護を提供します。 圧縮を提供することもあります。


   Key exchange method, public key algorithm, symmetric encryption
   algorithm, message authentication algorithm, and hash algorithm are
   all negotiated.

鍵交換方式、公開鍵アルゴリズム、対称暗号化アルゴリズム、メッセージ認証アルゴリズム、およびハッシュアルゴリズムはすべてネゴシエートされます。


   This document also describes the Diffie-Hellman key exchange method
   and the minimal set of algorithms that are needed to implement the
   SSH transport layer protocol.

このドキュメントでは、Diffie-Hellman鍵交換方法と、SSHトランスポート層プロトコルの実装に必要な最小限のアルゴリズムセットについても説明します。













Ylonen &  Lonvick           Standards Track                     [Page 1]

RFC 4253              SSH Transport Layer Protocol          January 2006


Table of Contents

目次


   1. Introduction ....................................................3
   2. Contributors ....................................................3
   3. Conventions Used in This Document ...............................3
   4. Connection Setup ................................................4
      4.1. Use over TCP/IP ............................................4
      4.2. Protocol Version Exchange ..................................4
   5. Compatibility With Old SSH Versions .............................5
      5.1. Old Client, New Server .....................................6
      5.2. New Client, Old Server .....................................6
      5.3. Packet Size and Overhead ...................................6
   6. Binary Packet Protocol ..........................................7
      6.1. Maximum Packet Length ......................................8
      6.2. Compression ................................................8
      6.3. Encryption .................................................9
      6.4. Data Integrity ............................................12
      6.5. Key Exchange Methods ......................................13
      6.6. Public Key Algorithms .....................................13
   7. Key Exchange ...................................................15
      7.1. Algorithm Negotiation .....................................17
      7.2. Output from Key Exchange ..................................20
      7.3. Taking Keys Into Use ......................................21
   8. Diffie-Hellman Key Exchange ....................................21
      8.1. diffie-hellman-group1-sha1 ................................23
      8.2. diffie-hellman-group14-sha1 ...............................23
   9. Key Re-Exchange ................................................23
   10. Service Request ...............................................24
   11. Additional Messages ...........................................25
      11.1. Disconnection Message ....................................25
      11.2. Ignored Data Message .....................................26
      11.3. Debug Message ............................................26
      11.4. Reserved Messages ........................................27
   12. Summary of Message Numbers ....................................27
   13. IANA Considerations ...........................................27
   14. Security Considerations .......................................28
   15. References ....................................................29
      15.1. Normative References .....................................29
      15.2. Informative References ...................................30
   Authors' Addresses ................................................31
   Trademark Notice ..................................................31
   1.はじめに............................................... ..... 3
   2.貢献者............................................... ..... 3
   3.このドキュメントで使用されている表記法...........................3
   4.接続設定.............................................. ..4
      4.1. TCP / IP経由での使用.......................................4
      4.2.プロトコルバージョン交換....................................4
   5.古いSSHバージョンとの互換性............................. 5
      5.1.古いクライアント、新しいサーバー............................6
      5.2.新しいクライアント、古いサーバー............................6
      5.3.パケットサイズとオーバーヘッド..............................6
   6.バイナリパケットプロトコル.......................................7
      6.1.最大パケット長..............................................8
      6.2.圧縮........................................................8
      6.3.暗号化......................................................9
      6.4.データの整合性..............................................12
      6.5.主要な交換方法..............................................13
      6.6.公開鍵アルゴリズム..................................... 13
   7.キー交換.............................................. ..... 15
      7.1.アルゴリズム交渉..................................... 17
      7.2.鍵交換からの出力.................................. 20
      7.3.キーを使用する..............................................21
   8. Diffie-Hellman鍵交換.................................. 21
      8.1. diffie-hellman-group1-sha1 ................................23
      8.2. diffie-hellman-group14-sha1 ...............................23
   9.主要な再交換.....................................................23
   10.サービスリクエスト..............................................24
   11.追加メッセージ........................................... 25
      11.1切断メッセージ.................................... 25
      11.2無視されたデータメッセージ..................................26
      11.3.デバッグメッセージ.........................................26
      11.4.予約メッセージ........................................ 27
   12.メッセージ番号の概要............................................27
   13. IANAの考慮事項........................................... 27
   14.セキュリティに関する考慮事項....................................28
   15.参考資料........................................................29
      15.1.規範的な参考文献..................................... 29
      15.2.有益な参照................................... 30
   著者のアドレス............................................... .31
   商標に関する通知...................................................31










Ylonen &  Lonvick           Standards Track                     [Page 2]

RFC 4253              SSH Transport Layer Protocol          January 2006


1.  Introduction

1.はじめに


   The SSH transport layer is a secure, low level transport protocol.
   It provides strong encryption, cryptographic host authentication, and
   integrity protection.

SSHトランスポート層は、安全な低レベルのトランスポートプロトコルです。 強力な暗号化、暗号ホスト認証、および整合性保護を提供します。


   Authentication in this protocol level is host-based; this protocol
   does not perform user authentication.  A higher level protocol for
   user authentication can be designed on top of this protocol.

このプロトコルレベルの認証はホストベースです。 このプロトコルはユーザー認証を行いません。 ユーザー認証のためのより高いレベルのプロトコルは、このプロトコルの上に設計することができます。


   The protocol has been designed to be simple and flexible to allow
   parameter negotiation, and to minimize the number of round-trips.
   The key exchange method, public key algorithm, symmetric encryption
   algorithm, message authentication algorithm, and hash algorithm are
   all negotiated.  It is expected that in most environments, only 2
   round-trips will be needed for full key exchange, server
   authentication, service request, and acceptance notification of
   service request.  The worst case is 3 round-trips.

このプロトコルは、パラメータネゴシエーションを可能にし、ラウンドトリップの数を最小限に抑えるために、シンプルで柔軟になるように設計されています。 鍵交換方式、公開鍵アルゴリズム、対称暗号化アルゴリズム、メッセージ認証アルゴリズム、およびハッシュアルゴリズムはすべてネゴシエートされます。 ほとんどの環境では、完全な鍵交換、サーバー認証、サービス要求、およびサービス要求の受け入れ通知に必要な往復は2回だけです。 最悪のケースは3往復です。


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]で説明されているように解釈されます。







Ylonen &  Lonvick           Standards Track                     [Page 3]

RFC 4253              SSH Transport Layer Protocol          January 2006


   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    データ

   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.  Connection Setup

4.接続設定


   SSH works over any 8-bit clean, binary-transparent transport.  The
   underlying transport SHOULD protect against transmission errors, as
   such errors cause the SSH connection to terminate.

SSHは、8ビットのクリーンなバイナリ透過トランスポートで動作します。 基礎となるトランスポートは、送信エラーがSSH接続を終了させる原因となるため、送信エラーから保護する必要があります(SHOULD)。


   The client initiates the connection.

クライアントが接続を開始します。


4.1.  Use over TCP/IP

4.1。 TCP / IP経由で使用


   When used over TCP/IP, the server normally listens for connections on
   port 22.  This port number has been registered with the IANA, and has
   been officially assigned for SSH.

TCP / IPを介して使用する場合、サーバーは通常、ポート22で接続を待機します。 このポート番号はIANAに登録されており、SSHに正式に割り当てられています。


4.2.  Protocol Version Exchange

4.2。 プロトコルバージョン交換


   When the connection has been established, both sides MUST send an
   identification string.  This identification string MUST be

接続が確立されると、両側が識別文字列を送信する必要があります。 この識別文字列は


      SSH-protoversion-softwareversion SP comments CR LF

SSH-protoversion-softwareversion SPコメントCR LF


   Since the protocol being defined in this set of documents is version
   2.0, the 'protoversion' MUST be "2.0".  The 'comments' string is
   OPTIONAL.  If the 'comments' string is included, a 'space' character
   (denoted above as SP, ASCII 32) MUST separate the 'softwareversion'
   and 'comments' strings.  The identification MUST be terminated by a
   single Carriage Return (CR) and a single Line Feed (LF) character
   (ASCII 13 and 10, respectively).  Implementers who wish to maintain



Ylonen &  Lonvick           Standards Track                     [Page 4]

RFC 4253              SSH Transport Layer Protocol          January 2006


   compatibility with older, undocumented versions of this protocol may
   want to process the identification string without expecting the
   presence of the carriage return character for reasons described in
   Section 5 of this document.  The null character MUST NOT be sent.
   The maximum length of the string is 255 characters, including the
   Carriage Return and Line Feed.

このドキュメントセットで定義されているプロトコルはバージョン2.0であるため、「プロトコルバージョン」は「2.0」でなければなりません。 「コメント」文字列はオプションです。 'comments'文字列が含まれている場合、 'space'文字(上記ではSP、ASCII 32と表記)は 'softwareversion'文字列と 'comments'文字列を区切る必要があります。 識別は、単一のキャリッジリターン(CR)と単一のラインフィード(LF)文字(それぞれASCII 13および10)で終了する必要があります。 このプロトコルのドキュメント化されていない古いバージョンとの互換性を維持したい実装者は、このドキュメントのセクション5で説明されている理由により、キャリッジリターン文字の存在を予期せずに識別文字列を処理したい場合があります。 ヌル文字を送信してはなりません。 文字列の最大長は、キャリッジリターンとラインフィードを含めて255文字です。


   The part of the identification string preceding the Carriage Return
   and Line Feed is used in the Diffie-Hellman key exchange (see Section
   8).

キャリッジリターンとラインフィードの前の識別文字列の一部は、Diffie-Hellman鍵交換で使用されます(セクション8を参照)。


   The server MAY send other lines of data before sending the version
   string.  Each line SHOULD be terminated by a Carriage Return and Line
   Feed.  Such lines MUST NOT begin with "SSH-", and SHOULD be encoded
   in ISO-10646 UTF-8 [RFC3629] (language is not specified).  Clients
   MUST be able to process such lines.  Such lines MAY be silently
   ignored, or MAY be displayed to the client user.  If they are
   displayed, control character filtering, as discussed in [SSH-ARCH],
   SHOULD be used.  The primary use of this feature is to allow TCP-
   wrappers to display an error message before disconnecting.

サーバーは、バージョン文字列を送信する前に、他のデータ行を送信してもよい(MAY)。 各ラインは、キャリッジリターンとラインフィードで終了する必要があります。 そのような行は「SSH-」で始めてはならず、ISO-10646 UTF-8 [RFC3629]でエンコードする必要があります(言語は指定されていません)。 クライアントはそのような行を処理できなければなりません。 そのような行は黙って無視されるかもしれません、またはクライアントユーザーに表示されるかもしれません。 それらが表示される場合は、[SSH-ARCH]で説明されているように、文字フィルタリングを制御し、SHOULDを使用する必要があります。 この機能の主な用途は、TCPラッパーが切断前にエラーメッセージを表示できるようにすることです。


   Both the 'protoversion' and 'softwareversion' strings MUST consist of
   printable US-ASCII characters, with the exception of whitespace
   characters and the minus sign (-).  The 'softwareversion' string is
   primarily used to trigger compatibility extensions and to indicate
   the capabilities of an implementation.  The 'comments' string SHOULD
   contain additional information that might be useful in solving user
   problems.  As such, an example of a valid identification string is

'protoversion'と 'softwareversion'の両方の文字列は、空白文字とマイナス記号(-)を除いて、印刷可能なUS-ASCII文字で構成する必要があります。 'softwareversion'文字列は、主に互換性拡張機能をトリガーし、実装の機能を示すために使用されます。 「コメント」文字列には、ユーザーの問題の解決に役立つ可能性がある追加情報が含まれている必要があります(SHOULD)。 そのため、有効な識別文字列の例は次のとおりです。


      SSH-2.0-billsSSH_3.6.3q3<CR><LF>

   This identification string does not contain the optional 'comments'
   string and is thus terminated by a CR and LF immediately after the
   'softwareversion' string.

この識別文字列にはオプションの「コメント」文字列が含まれていないため、「ソフトウェアバージョン」文字列の直後にCRおよびLFで終了します。


   Key exchange will begin immediately after sending this identifier.
   All packets following the identification string SHALL use the binary
   packet protocol, which is described in Section 6.

この識別子を送信した直後にキー交換が開始されます。 識別文字列に続くすべてのパケットは、セクション6で説明されているバイナリパケットプロトコルを使用するものとします(SHALL)。


5.  Compatibility With Old SSH Versions

5.古いSSHバージョンとの互換性


   As stated earlier, the 'protoversion' specified for this protocol is
   "2.0".  Earlier versions of this protocol have not been formally
   documented, but it is widely known that they use 'protoversion' of
   "1.x" (e.g., "1.5" or "1.3").  At the time of this writing, many
   implementations of SSH are utilizing protocol version 2.0, but it is
   known that there are still devices using the previous versions.
   During the transition period, it is important to be able to work in a



Ylonen &  Lonvick           Standards Track                     [Page 5]

RFC 4253              SSH Transport Layer Protocol          January 2006


   way that is compatible with the installed SSH clients and servers
   that use the older version of the protocol.  Information in this
   section is only relevant for implementations supporting compatibility
   with SSH versions 1.x.  For those interested, the only known
   documentation of the 1.x protocol is contained in README files that
   are shipped along with the source code [ssh-1.2.30].

前に述べたように、このプロトコルに指定された「プロトコルバージョン」は「2.0」です。 このプロトコルの以前のバージョンは正式に文書化されていませんが、「1.x」(「1.5」や「1.3」など)の「プロトコルバージョン」を使用していることが広く知られています。 この記事の執筆時点では、SSHの多くの実装でプロトコルバージョン2.0が使用されていますが、以前のバージョンを使用しているデバイスがまだあることがわかっています。 移行期間中、古いバージョンのプロトコルを使用するインストール済みのSSHクライアントおよびサーバーと互換性のある方法で作業できることが重要です。 このセクションの情報は、SSHバージョン1.xとの互換性をサポートする実装にのみ関連しています。 興味のある方のために、1.xプロトコルの唯一の既知のドキュメントは、ソースコード[ssh-1.2.30]と一緒に出荷されるREADMEファイルに含まれています。


5.1.  Old Client, New Server

5.1。 古いクライアント、新しいサーバー


   Server implementations MAY support a configurable compatibility flag
   that enables compatibility with old versions.  When this flag is on,
   the server SHOULD identify its 'protoversion' as "1.99".  Clients
   using protocol 2.0 MUST be able to identify this as identical to
   "2.0".  In this mode, the server SHOULD NOT send the Carriage Return
   character (ASCII 13) after the identification string.

サーバーの実装は、古いバージョンとの互換性を有効にする構成可能な互換性フラグをサポートする場合があります。 このフラグがオンの場合、サーバーは「プロトバージョン」を「1.99」として識別する必要があります。 プロトコル2.0を使用するクライアントは、これを「2.0」と同一として識別できる必要があります。 このモードでは、サーバーは識別文字列の後にキャリッジリターン文字(ASCII 13)を送信しないでください。


   In the compatibility mode, the server SHOULD NOT send any further
   data after sending its identification string until it has received an
   identification string from the client.  The server can then determine
   whether the client is using an old protocol, and can revert to the
   old protocol if required.  In the compatibility mode, the server MUST
   NOT send additional data before the identification string.

互換モードでは、サーバーは、クライアントから識別文字列を受信するまで、その識別文字列を送信した後、それ以上データを送信しないでください。 サーバーは、クライアントが古いプロトコルを使用しているかどうかを判断し、必要に応じて古いプロトコルに戻すことができます。 互換モードでは、サーバーは識別文字列の前に追加のデータを送信してはなりません(MUST NOT)。


   When compatibility with old clients is not needed, the server MAY
   send its initial key exchange data immediately after the
   identification string.

古いクライアントとの互換性が必要ない場合、サーバーは識別文字列の直後に最初の鍵交換データを送信してもよい(MAY)。


5.2.  New Client, Old Server

5.2。 新しいクライアント、古いサーバー


   Since the new client MAY immediately send additional data after its
   identification string (before receiving the server's identification
   string), the old protocol may already be corrupt when the client
   learns that the server is old.  When this happens, the client SHOULD
   close the connection to the server, and reconnect using the old
   protocol.

新しいクライアントは、識別文字列の後に(サーバーの識別文字列を受信する前に)すぐに追加のデータを送信する可能性があるため(MAY)、サーバーが古いことをクライアントが知ると、古いプロトコルはすでに壊れている可能性があります。 これが発生した場合、クライアントはサーバーへの接続を閉じて、古いプロトコルを使用して再接続する必要があります(SHOULD)。


5.3.  Packet Size and Overhead

5.3。 パケットサイズとオーバーヘッド


   Some readers will worry about the increase in packet size due to new
   headers, padding, and the Message Authentication Code (MAC).  The
   minimum packet size is in the order of 28 bytes (depending on
   negotiated algorithms).  The increase is negligible for large
   packets, but very significant for one-byte packets (telnet-type
   sessions).  There are, however, several factors that make this a
   non-issue in almost all cases:

一部のリーダーは、新しいヘッダー、パディング、およびメッセージ認証コード(MAC)によるパケットサイズの増加を心配します。 最小パケットサイズは28バイト程度です(ネゴシエートされたアルゴリズムによって異なります)。 大きなパケットの場合、この増加は無視できますが、1バイトのパケット(telnetタイプのセッション)の場合は非常に大きくなります。 ただし、ほとんどすべての場合にこれを問題としないいくつかの要因があります。


   o  The minimum size of a TCP/IP header is 32 bytes.  Thus, the
      increase is actually from 33 to 51 bytes (roughly).

o TCP / IPヘッダーの最小サイズは32バイトです。 したがって、増加は実際には33バイトから51バイトになります(大体)。




Ylonen &  Lonvick           Standards Track                     [Page 6]

RFC 4253              SSH Transport Layer Protocol          January 2006


   o  The minimum size of the data field of an Ethernet packet is 46
      bytes [RFC0894].  Thus, the increase is no more than 5 bytes.
      When Ethernet headers are considered, the increase is less than 10
      percent.

oイーサネットパケットのデータフィールドの最小サイズは46バイトです[RFC0894]。 したがって、増加は5バイトを超えません。 イーサネットヘッダーを考慮すると、増加は10%未満です。


   o  The total fraction of telnet-type data in the Internet is
      negligible, even with increased packet sizes.

oパケットサイズが大きくなっても、インターネット内のtelnetタイプのデータの割合はごくわずかです。


   The only environment where the packet size increase is likely to have
   a significant effect is PPP [RFC1661] over slow modem lines (PPP
   compresses the TCP/IP headers, emphasizing the increase in packet
   size).  However, with modern modems, the time needed to transfer is
   in the order of 2 milliseconds, which is a lot faster than people can
   type.

パケットサイズの増加が大きな影響を与える可能性がある唯一の環境は、低速モデム回線を介したPPP [RFC1661]です(PPPはTCP / IPヘッダーを圧縮し、パケットサイズの増加を強調します)。 ただし、最近のモデムでは、転送に必要な時間は約2ミリ秒であり、これはユーザーが入力するよりもはるかに高速です。


   There are also issues related to the maximum packet size.  To
   minimize delays in screen updates, one does not want excessively
   large packets for interactive sessions.  The maximum packet size is
   negotiated separately for each channel.

最大パケットサイズに関連する問題もあります。 画面更新の遅延を最小限に抑えるために、対話型セッションに過度に大きなパケットが必要になることはありません。 最大パケットサイズは、チャネルごとに個別にネゴシエートされます。


6.  Binary Packet Protocol

6.バイナリパケットプロトコル


   Each packet is in the following format:

各パケットは次の形式です。


      uint32    packet_length
      byte      padding_length
      byte[n1]  payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length
      byte[m]   mac (Message Authentication Code - MAC); m = mac_length
      uint32    packet_length
      byte      padding_length
      byte[n1]  ペイロード; n1 = packet_length-padding_length-1
      byte[n2]  ランダムパディング; n2 = padding_length
      byte[m]   mac(メッセージ認証コード-MAC); m = mac_length

      packet_length

packet_length

         The length of the packet in bytes, not including 'mac' or the
         'packet_length' field itself.

「mac」または「packet_length」フィールド自体を含まない、バイト単位のパケットの長さ。


      padding_length

padding_length

         Length of 'random padding' (bytes).

「ランダムパディング」の長さ(バイト)。


      payload

ペイロード

         The useful contents of the packet.  If compression has been
         negotiated, this field is compressed.  Initially, compression
         MUST be "none".

パケットの有用な内容。 圧縮がネゴシエートされている場合、このフィールドは圧縮されています。 最初は、圧縮は「なし」でなければなりません。


      random padding

ランダムパディング

         Arbitrary-length padding, such that the total length of
         (packet_length || padding_length || payload || random padding)
         is a multiple of the cipher block size or 8, whichever is





Ylonen &  Lonvick           Standards Track                     [Page 7]

RFC 4253              SSH Transport Layer Protocol          January 2006


         larger.  There MUST be at least four bytes of padding.  The
         padding SHOULD consist of random bytes.  The maximum amount of
         padding is 255 bytes.

(packet_length || padding_length || payload || random padding)の全長が暗号ブロックサイズの倍数または8のいずれか大きい方になるような、任意の長さのパディング。 少なくとも4バイトのパディングが必要です。 パディングはランダムなバイトで構成する必要があります(SHOULD)。 パディングの最大量は255バイトです。


      mac

マック

         Message Authentication Code.  If message authentication has
         been negotiated, this field contains the MAC bytes.  Initially,
         the MAC algorithm MUST be "none".

メッセージ認証コード。 メッセージ認証がネゴシエートされた場合、このフィールドにはMACバイトが含まれます。 最初は、MACアルゴリズムは「なし」でなければなりません。


   Note that the length of the concatenation of 'packet_length',
   'padding_length', 'payload', and 'random padding' MUST be a multiple
   of the cipher block size or 8, whichever is larger.  This constraint
   MUST be enforced, even when using stream ciphers.  Note that the
   'packet_length' field is also encrypted, and processing it requires
   special care when sending or receiving packets.  Also note that the
   insertion of variable amounts of 'random padding' may help thwart
   traffic analysis.

「packet_length」、「padding_length」、「payload」、「random padding」の連結の長さは、暗号ブロックサイズの倍数または8のいずれか大きいほうである必要があることに注意してください。 ストリーム暗号を使用する場合でも、この制約を強制する必要があります。 「packet_length」フィールドも暗号化されていることに注意してください。パケットの送信または受信時には、その処理に特別な注意が必要です。 また、可変量の「ランダムパディング」を挿入すると、トラフィック分析を阻止できる場合があります。


   The minimum size of a packet is 16 (or the cipher block size,
   whichever is larger) bytes (plus 'mac').  Implementations SHOULD
   decrypt the length after receiving the first 8 (or cipher block size,
   whichever is larger) bytes of a packet.

パケットの最小サイズは16バイト(または暗号ブロックサイズのいずれか大きい方)バイト(および「mac」)です。 実装は、パケットの最初の8バイト(または暗号ブロックサイズ、どちらか大きい方)を受信した後に長さを復号化する必要があります(SHOULD)。


6.1.  Maximum Packet Length

6.1。 最大パケット長


   All implementations MUST be able to process packets with an
   uncompressed payload length of 32768 bytes or less and a total packet
   size of 35000 bytes or less (including 'packet_length',
   'padding_length', 'payload', 'random padding', and 'mac').  The
   maximum of 35000 bytes is an arbitrarily chosen value that is larger
   than the uncompressed length noted above.  Implementations SHOULD
   support longer packets, where they might be needed.  For example, if
   an implementation wants to send a very large number of certificates,
   the larger packets MAY be sent if the identification string indicates
   that the other party is able to process them.  However,
   implementations SHOULD check that the packet length is reasonable in
   order for the implementation to avoid denial of service and/or buffer
   overflow attacks.

すべての実装は、32768バイト以下の非圧縮ペイロード長と35000バイト以下の合計パケットサイズ(「packet_length」、「padding_length」、「payload」、「random padding」、および「mac」を含む)でパケットを処理できる必要があります ')。 最大35000バイトは、任意に選択した値であり、上記の非圧縮長よりも大きくなります。 実装は、必要な場合に、より長いパケットをサポートする必要があります(SHOULD)。 たとえば、実装が非常に多数の証明書を送信したい場合、相手がそれらを処理できることを識別文字列が示すと、より大きなパケットが送信される可能性があります。 ただし、実装では、サービス拒否攻撃やバッファオーバーフロー攻撃を回避するために、パケット長が妥当であることを確認する必要があります(SHOULD)。


6.2.  Compression

6.2。 圧縮


   If compression has been negotiated, the 'payload' field (and only it)
   will be compressed using the negotiated algorithm.  The
   'packet_length' field and 'mac' will be computed from the compressed
   payload.  Encryption will be done after compression.

圧縮がネゴシエートされている場合、「ペイロード」フィールド(およびそれのみ)は、ネゴシエートされたアルゴリズムを使用して圧縮されます。 「packet_length」フィールドと「mac」は、圧縮されたペイロードから計算されます。 暗号化は圧縮後に行われます。







Ylonen &  Lonvick           Standards Track                     [Page 8]

RFC 4253              SSH Transport Layer Protocol          January 2006


   Compression MAY be stateful, depending on the method.  Compression
   MUST be independent for each direction, and implementations MUST
   allow independent choosing of the algorithm for each direction.  In
   practice however, it is RECOMMENDED that the compression method be
   the same in both directions.

メソッドに応じて、圧縮はステートフルになる場合があります。 圧縮は方向ごとに独立している必要があり、実装では、方向ごとにアルゴリズムを独立して選択できる必要があります。 ただし、実際には、圧縮方法を両方向で同じにすることをお勧めします。


   The following compression methods are currently defined:

現在、次の圧縮方法が定義されています。


      none     REQUIRED        no compression
      zlib     OPTIONAL        ZLIB (LZ77) compression
      none     必須            圧縮なし
      zlib     オプション      ZLIB(LZ77)圧縮

   The "zlib" compression is described in [RFC1950] and in [RFC1951].
   The compression context is initialized after each key exchange, and
   is passed from one packet to the next, with only a partial flush
   being performed at the end of each packet.  A partial flush means
   that the current compressed block is ended and all data will be
   output.  If the current block is not a stored block, one or more
   empty blocks are added after the current block to ensure that there
   are at least 8 bits, counting from the start of the end-of-block code
   of the current block to the end of the packet payload.

「zlib」圧縮は[RFC1950]と[RFC1951]で説明されています。 圧縮コンテキストは、各キー交換の後に初期化され、1つのパケットから次のパケットに渡され、各パケットの最後に部分的なフラッシュのみが実行されます。 部分フラッシュは、現在の圧縮ブロックが終了し、すべてのデータが出力されることを意味します。 現在のブロックが保存されたブロックではない場合、現在のブロックの後に、1つ以上の空のブロックが追加され、現在のブロックのブロックの終わりのコードの開始から最後まで、少なくとも8ビットあることを確認します パケットペイロードの。


   Additional methods may be defined as specified in [SSH-ARCH] and
   [SSH-NUMBERS].

[SSH-ARCH]と[SSH-NUMBERS]で指定されている追加のメソッドを定義できます。


6.3.  Encryption

6.3。 暗号化


   An encryption algorithm and a key will be negotiated during the key
   exchange.  When encryption is in effect, the packet length, padding
   length, payload, and padding fields of each packet MUST be encrypted
   with the given algorithm.

暗号化アルゴリズムとキーは、キー交換中にネゴシエートされます。 暗号化が有効な場合、各パケットのパケット長、パディング長、ペイロード、およびパディングフィールドは、指定されたアルゴリズムで暗号化される必要があります。


   The encrypted data in all packets sent in one direction SHOULD be
   considered a single data stream.  For example, initialization vectors
   SHOULD be passed from the end of one packet to the beginning of the
   next packet.  All ciphers SHOULD use keys with an effective key
   length of 128 bits or more.

一方向に送信されるすべてのパケットの暗号化されたデータは、単一のデータストリームと見なされるべきです(SHOULD)。 たとえば、初期化ベクトルは1つのパケットの終わりから次のパケットの始めに渡されるべきです(SHOULD)。 すべての暗号は、有効なキーの長さが128ビット以上のキーを使用する必要があります(SHOULD)。


   The ciphers in each direction MUST run independently of each other.
   Implementations MUST allow the algorithm for each direction to be
   independently selected, if multiple algorithms are allowed by local
   policy.  In practice however, it is RECOMMENDED that the same
   algorithm be used in both directions.

各方向の暗号は、互いに独立して実行する必要があります。 ローカルポリシーで複数のアルゴリズムが許可されている場合、実装では、各方向のアルゴリズムを個別に選択できるようにする必要があります。 ただし、実際には、同じアルゴリズムを両方向で使用することをお勧めします。










Ylonen &  Lonvick           Standards Track                     [Page 9]

RFC 4253              SSH Transport Layer Protocol          January 2006


   The following ciphers are currently defined:

現在、次の暗号が定義されています。


      3des-cbc         REQUIRED          three-key 3DES in CBC mode
      blowfish-cbc     OPTIONAL          Blowfish in CBC mode
      twofish256-cbc   OPTIONAL          Twofish in CBC mode,
                                         with a 256-bit key
      twofish-cbc      OPTIONAL          alias for "twofish256-cbc"
                                         (this is being retained
                                         for historical reasons)
      twofish192-cbc   OPTIONAL          Twofish with a 192-bit key
      twofish128-cbc   OPTIONAL          Twofish with a 128-bit key
      aes256-cbc       OPTIONAL          AES in CBC mode,
                                         with a 256-bit key
      aes192-cbc       OPTIONAL          AES with a 192-bit key
      aes128-cbc       RECOMMENDED       AES with a 128-bit key
      serpent256-cbc   OPTIONAL          Serpent in CBC mode, with
                                         a 256-bit key
      serpent192-cbc   OPTIONAL          Serpent with a 192-bit key
      serpent128-cbc   OPTIONAL          Serpent with a 128-bit key
      arcfour          OPTIONAL          the ARCFOUR stream cipher
                                         with a 128-bit key
      idea-cbc         OPTIONAL          IDEA in CBC mode
      cast128-cbc      OPTIONAL          CAST-128 in CBC mode
      none             OPTIONAL          no encryption; NOT RECOMMENDED
      3des-cbc         必須              CBCモードの3キー3DES
      blowfish-cbc     オプション        CBCモードのBlowfish
      twofish256-cbc   オプション        256ビットキーを使用したCBCモードのTwofish
      twofish-cbc      オプション        "twofish256-cbc"のエイリアス(これは
                                         歴史的な理由で保持されています)
      twofish192-cbc   オプション        192ビットキーのTwofish
      twofish128-cbc   オプション        128ビットキーのTwofish
      aes256-cbc       オプション        256ビットキーを使用したCBCモードのAES
      aes192-cbc       オプション        192ビットキーのAES
      aes128-cbc       推奨              128ビットキーのAES
      serpent256-cbc   オプション        CBCモードの蛇、256ビットキー
      serpent192-cbc   オプション        192ビットキーを持つ蛇
      serpent128-cbc   オプション        128ビットキーを持つ蛇
      arcfour          オプション        128ビットキーのARCFOURストリーム暗号
      idea-cbc         オプション        CBCモードのIDEA
      cast128-cbc      オプション        CBCモードのCAST-128
      none             オプション        暗号化なし。 推奨されません

   The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
   encrypt), where the first 8 bytes of the key are used for the first
   encryption, the next 8 bytes for the decryption, and the following 8
   bytes for the final encryption.  This requires 24 bytes of key data
   (of which 168 bits are actually used).  To implement CBC mode, outer
   chaining MUST be used (i.e., there is only one initialization
   vector).  This is a block cipher with 8-byte blocks.  This algorithm
   is defined in [FIPS-46-3].  Note that since this algorithm only has
   an effective key length of 112 bits ([SCHNEIER]), it does not meet
   the specifications that SSH encryption algorithms should use keys of
   128 bits or more.  However, this algorithm is still REQUIRED for
   historical reasons; essentially, all known implementations at the
   time of this writing support this algorithm, and it is commonly used
   because it is the fundamental interoperable algorithm.  At some
   future time, it is expected that another algorithm, one with better
   strength, will become so prevalent and ubiquitous that the use of
   "3des-cbc" will be deprecated by another STANDARDS ACTION.

「3des-cbc」暗号は3つのキーのTriple-DES(暗号化-復号化-暗号化)であり、キーの最初の8バイトが最初の暗号化に使用され、次の8バイトが復号化に使用され、次の8バイトが使用されます。最終的な暗号化のため。 これには24バイトのキーデータが必要です(そのうち168ビットが実際に使用されます)。 CBCモードを実装するには、外部チェーンを使用する必要があります(つまり、初期化ベクトルは1つだけです)。 これは、8バイトのブロックを持つブロック暗号です。 このアルゴリズムは[FIPS-46-3]で定義されています。 このアルゴリズムは有効なキーの長さが112ビット([SCHNEIER])しかないため、SSH暗号化アルゴリズムが128ビット以上のキーを使用するという仕様を満たしていません。 ただし、歴史的な理由により、このアルゴリズムは依然として必要です。基本的に、これを書いている時点でのすべての既知の実装はこのアルゴリズムをサポートしており、基本的な相互運用可能なアルゴリズムであるため、一般的に使用されています。 将来的には、より優れた強度を持つ別のアルゴリズムが普及し、ユビキタスになるため、「3des-cbc」の使用は別の標準アクションによって非推奨になると予想されます。


   The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128-bit keys
   [SCHNEIER].  This is a block cipher with 8-byte blocks.

"blowfish-cbc"暗号はCBCモードのBlowfishで、128ビットの鍵を使用しています[SCHNEIER]。 これは、8バイトのブロックを持つブロック暗号です。







Ylonen &  Lonvick           Standards Track                    [Page 10]

RFC 4253              SSH Transport Layer Protocol          January 2006


   The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,
   with 256-bit keys as described [TWOFISH].  This is a block cipher
   with 16-byte blocks.

「twofish-cbc」または「twofish256-cbc」暗号は、CBCモードのTwofishであり、[TWOFISH]で説明されているように256ビットの鍵を使用します。 これは、16バイトのブロックを持つブロック暗号です。


   The "twofish192-cbc" cipher is the same as above, but with a 192-bit
   key.

「twofish192-cbc」暗号は上記と同じですが、192ビットの鍵を使用します。


   The "twofish128-cbc" cipher is the same as above, but with a 128-bit
   key.

「twofish128-cbc」暗号は上記と同じですが、128ビットの鍵が使用されます。


   The "aes256-cbc" cipher is AES (Advanced Encryption Standard)
   [FIPS-197], in CBC mode.  This version uses a 256-bit key.

「aes256-cbc」暗号は、CBCモードのAES(Advanced Encryption Standard)[FIPS-197]です。 このバージョンは256ビットのキーを使用します。


   The "aes192-cbc" cipher is the same as above, but with a 192-bit key.

「aes192-cbc」暗号は上記と同じですが、192ビットの鍵を使用します。


   The "aes128-cbc" cipher is the same as above, but with a 128-bit key.

「aes128-cbc」暗号は上記と同じですが、128ビットの鍵が使用されます。


   The "serpent256-cbc" cipher in CBC mode, with a 256-bit key as
   described in the Serpent AES submission.

CBCモードの「serpent256-cbc」暗号。SerpentAESの提出に記載されている256ビットの鍵を使用します。


   The "serpent192-cbc" cipher is the same as above, but with a 192-bit
   key.

「serpent192-cbc」暗号は上記と同じですが、192ビットの鍵を使用します。


   The "serpent128-cbc" cipher is the same as above, but with a 128-bit
   key.

「serpent128-cbc」暗号は上記と同じですが、128ビットの鍵が使用されます。


   The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
   The Arcfour cipher is believed to be compatible with the RC4 cipher
   [SCHNEIER].  Arcfour (and RC4) has problems with weak keys, and
   should be used with caution.

「arcfour」暗号は、128ビットの鍵を持つArcfourストリーム暗号です。 Arcfour暗号は、RC4暗号[SCHNEIER]と互換性があると考えられています。 Arcfour(およびRC4)はキーが弱いという問題があるため、注意して使用する必要があります。


   The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].

「idea-cbc」暗号は、CBCモードでのIDEA暗号です[SCHNEIER]。


   The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode with a
   128-bit key [RFC2144].

「cast128-cbc」暗号は、128ビットの鍵を使用したCBCモードのCAST-128暗号です[RFC2144]。


   The "none" algorithm specifies that no encryption is to be done.
   Note that this method provides no confidentiality protection, and it
   is NOT RECOMMENDED.  Some functionality (e.g., password
   authentication) may be disabled for security reasons if this cipher
   is chosen.

「なし」アルゴリズムは、暗号化を行わないことを指定します。 この方法は機密保護を提供しないため、推奨されないことに注意してください。 この暗号を選択すると、セキュリティ上の理由から一部の機能(パスワード認証など)が無効になる場合があります。


   Additional methods may be defined as specified in [SSH-ARCH] and in
   [SSH-NUMBERS].

[SSH-ARCH]および[SSH-NUMBERS]で指定されているように、追加のメソッドを定義できます。








Ylonen &  Lonvick           Standards Track                    [Page 11]

RFC 4253              SSH Transport Layer Protocol          January 2006


6.4.  Data Integrity

6.4。 データの整合性


   Data integrity is protected by including with each packet a MAC that
   is computed from a shared secret, packet sequence number, and the
   contents of the packet.

各パケットに、共有シークレット、パケットシーケンス番号、およびパケットの内容から計算されるMACを含めることにより、データの整合性が保護されます。


   The message authentication algorithm and key are negotiated during
   key exchange.  Initially, no MAC will be in effect, and its length
   MUST be zero.  After key exchange, the 'mac' for the selected MAC
   algorithm will be computed before encryption from the concatenation
   of packet data:

メッセージ認証アルゴリズムとキーは、キー交換中にネゴシエートされます。 最初は、有効なMACはなく、その長さはゼロでなければなりません。 鍵交換後、パケットデータの連結から暗号化する前に、選択したMACアルゴリズムの「mac」が計算されます。


      mac = MAC(key, sequence_number || unencrypted_packet)

   where unencrypted_packet is the entire packet without 'mac' (the
   length fields, 'payload' and 'random padding'), and sequence_number
   is an implicit packet sequence number represented as uint32.  The
   sequence_number is initialized to zero for the first packet, and is
   incremented after every packet (regardless of whether encryption or
   MAC is in use).  It is never reset, even if keys/algorithms are
   renegotiated later.  It wraps around to zero after every 2^32
   packets.  The packet sequence_number itself is not included in the
   packet sent over the wire.

ここで、unencrypted_packetは「mac」を含まないパケット全体(長さフィールド、「payload」、「random padding」)であり、sequence_numberはuint32として表される暗黙のパケットシーケンス番号です。 sequence_numberは、最初のパケットに対してゼロに初期化され、すべてのパケットの後に増分されます(暗号化またはMACが使用されているかどうかに関係なく)。 後でキー/アルゴリズムが再ネゴシエートされても、リセットされることはありません。 2 ^ 32パケットごとにゼロに折り返します。 パケットのsequence_number自体は、回線を介して送信されるパケットには含まれません。


   The MAC algorithms for each direction MUST run independently, and
   implementations MUST allow choosing the algorithm independently for
   both directions.  In practice however, it is RECOMMENDED that the
   same algorithm be used in both directions.

各方向のMACアルゴリズムは独立して実行する必要があり、実装では両方向のアルゴリズムを独立して選択できる必要があります。 ただし、実際には、同じアルゴリズムを両方向で使用することをお勧めします。


   The value of 'mac' resulting from the MAC algorithm MUST be
   transmitted without encryption as the last part of the packet.  The
   number of 'mac' bytes depends on the algorithm chosen.

MACアルゴリズムから得られる「mac」の値は、パケットの最後の部分として暗号化せずに送信する必要があります。 「mac」バイトの数は、選択したアルゴリズムによって異なります。


   The following MAC algorithms are currently defined:

現在、次のMACアルゴリズムが定義されています。


      hmac-sha1    REQUIRED        HMAC-SHA1 (digest length = key
                                   length = 20)
      hmac-sha1-96 RECOMMENDED     first 96 bits of HMAC-SHA1 (digest
                                   length = 12, key length = 20)
      hmac-md5     OPTIONAL        HMAC-MD5 (digest length = key
                                   length = 16)
      hmac-md5-96  OPTIONAL        first 96 bits of HMAC-MD5 (digest
                                   length = 12, key length = 16)
      none         OPTIONAL        no MAC; NOT RECOMMENDED
      hmac-sha1    必須            HMAC-SHA1(ダイジェストの長さ=キーの長さ= 20)
      hmac-sha1-96 推奨            HMAC-SHA1の最初の96ビット
                                   (ダイジェスト長= 12、キー長= 20)
      hmac-md5     オプション      HMAC-MD5(ダイジェスト長=キー長= 16)
      hmac-md5-96  オプション      HMAC-MD5の最初の96ビット
                                  (ダイジェスト長= 12、キー長= 16)
      none         オプション      MACなし。 推奨されません

   The "hmac-*" algorithms are described in [RFC2104].  The "*-n" MACs
   use only the first n bits of the resulting value.

「hmac- *」アルゴリズムは[RFC2104]で説明されています。 "* -n" MACは、結果の値の最初のnビットのみを使用します。





Ylonen &  Lonvick           Standards Track                    [Page 12]

RFC 4253              SSH Transport Layer Protocol          January 2006


   SHA-1 is described in [FIPS-180-2] and MD5 is described in [RFC1321].

SHA-1は[FIPS-180-2]で説明されており、MD5は[RFC1321]で説明されています。


   Additional methods may be defined, as specified in [SSH-ARCH] and in
   [SSH-NUMBERS].

[SSH-ARCH]および[SSH-NUMBERS]で指定されているように、追加のメソッドを定義できます。


6.5.  Key Exchange Methods

6.5。 主な交換方法


   The key exchange method specifies how one-time session keys are
   generated for encryption and for authentication, and how the server
   authentication is done.

鍵交換方式では、暗号化と認証のためにワンタイムセッション鍵を生成する方法と、サーバー認証を行う方法を指定します。


   Two REQUIRED key exchange methods have been defined:

2つの必須の鍵交換方法が定義されています。


      diffie-hellman-group1-sha1 REQUIRED
      diffie-hellman-group14-sha1 REQUIRED

   These methods are described in Section 8.

これらのメソッドについては、セクション8で説明します。


   Additional methods may be defined as specified in [SSH-NUMBERS].  The
   name "diffie-hellman-group1-sha1" is used for a key exchange method
   using an Oakley group, as defined in [RFC2409].  SSH maintains its
   own group identifier space that is logically distinct from Oakley
   [RFC2412] and IKE; however, for one additional group, the Working
   Group adopted the number assigned by [RFC3526], using diffie-
   hellman-group14-sha1 for the name of the second defined group.
   Implementations should treat these names as opaque identifiers and
   should not assume any relationship between the groups used by SSH and
   the groups defined for IKE.

[SSH-NUMBERS]で指定されているように、追加のメソッドを定義できます。 [diffie-hellman-group1-sha1]という名前は、[RFC2409]で定義されているように、Oakleyグループを使用する鍵交換方法に使用されます。 SSHは、Oakley [RFC2412]およびIKEと論理的に異なる独自のグループ識別子スペースを維持します。 ただし、1つの追加グループについて、ワーキンググループは[RFC3526]によって割り当てられた番号を採用し、2番目に定義されたグループの名前にdiffie-hellman-group14-sha1を使用しました。 実装では、これらの名前を不透明な識別子として扱う必要があり、SSHで使用されるグループとIKEに定義されたグループの間の関係を想定しないでください。


6.6.  Public Key Algorithms

6.6。 公開鍵アルゴリズム


   This protocol has been designed to operate with almost any public key
   format, encoding, and algorithm (signature and/or encryption).

このプロトコルは、ほとんどすべての公開鍵フォーマット、エンコーディング、およびアルゴリズム(署名や暗号化)で動作するように設計されています。


   There are several aspects that define a public key type:

公開鍵タイプを定義するいくつかの側面があります。


   o  Key format: how is the key encoded and how are certificates
      represented.  The key blobs in this protocol MAY contain
      certificates in addition to keys.

oキー形式:キーのエンコード方法と証明書の表現方法。 このプロトコルのキーBLOBには、キーに加えて証明書が含まれている場合があります。


   o  Signature and/or encryption algorithms.  Some key types may not
      support both signing and encryption.  Key usage may also be
      restricted by policy statements (e.g., in certificates).  In this
      case, different key types SHOULD be defined for the different
      policy alternatives.

o署名および/または暗号化アルゴリズム。 一部の鍵タイプは、署名と暗号化の両方をサポートしていない場合があります。 キーの使用法は、ポリシーステートメント(証明書など)によっても制限される場合があります。 この場合、異なるポリシータイプに対して異なるキータイプを定義する必要があります(SHOULD)。


   o  Encoding of signatures and/or encrypted data.  This includes but
      is not limited to padding, byte order, and data formats.

o署名および/または暗号化されたデータのエンコード。 これには、パディング、バイト順序、およびデータ形式が含まれますが、これらに限定されません。




Ylonen &  Lonvick           Standards Track                    [Page 13]

RFC 4253              SSH Transport Layer Protocol          January 2006


   The following public key and/or certificate formats are currently
   defined:

現在、以下の公開鍵および/または証明書形式が定義されています。


   ssh-dss           REQUIRED     sign   Raw DSS Key
   ssh-rsa           RECOMMENDED  sign   Raw RSA Key
   pgp-sign-rsa      OPTIONAL     sign   OpenPGP certificates (RSA key)
   pgp-sign-dss      OPTIONAL     sign   OpenPGP certificates (DSS key)

   Additional key types may be defined, as specified in [SSH-ARCH] and
   in [SSH-NUMBERS].

[SSH-ARCH]と[SSH-NUMBERS]で指定されているように、追加の鍵タイプを定義できます。


   The key type MUST always be explicitly known (from algorithm
   negotiation or some other source).  It is not normally included in
   the key blob.

鍵のタイプは常に(アルゴリズムネゴシエーションまたはその他のソースから)明示的に認識されている必要があります。 通常、キーBLOBには含まれません。


   Certificates and public keys are encoded as follows:

証明書と公開鍵は次のようにエンコードされます。


      string    certificate or public key format identifier
      byte[n]   key/certificate data
      string    証明書または公開鍵形式の識別子
      byte[n]   キー/証明書データ

   The certificate part may be a zero length string, but a public key is
   required.  This is the public key that will be used for
   authentication.  The certificate sequence contained in the
   certificate blob can be used to provide authorization.

証明書の部分は長さがゼロの文字列でもかまいませんが、公開鍵が必要です。 これは、認証に使用される公開鍵です。 証明書BLOBに含まれる証明書シーケンスを使用して、承認を提供できます。


   Public key/certificate formats that do not explicitly specify a
   signature format identifier MUST use the public key/certificate
   format identifier as the signature identifier.

署名形式識別子を明示的に指定しない公開鍵/証明書形式は、署名識別子として公開鍵/証明書形式識別子を使用する必要があります。


   Signatures are encoded as follows:

署名は次のようにエンコードされます。


      string    signature format identifier (as specified by the
                public key/certificate format)
      byte[n]   signature blob in format specific encoding.
      string    署名形式識別子(公開鍵/証明書形式で指定)
      byte[n]   形式固有のエンコードの署名Blob。

   The "ssh-dss" key format has the following specific encoding:

「ssh-dss」キー形式には、次の特定のエンコーディングがあります。


      string    "ssh-dss"
      mpint     p
      mpint     q
      mpint     g
      mpint     y

   Here, the 'p', 'q', 'g', and 'y' parameters form the signature key
   blob.

ここで、「p」、「q」、「g」、および「y」パラメーターは、署名鍵BLOBを形成します。







Ylonen &  Lonvick           Standards Track                    [Page 14]

RFC 4253              SSH Transport Layer Protocol          January 2006


   Signing and verifying using this key format is done according to the
   Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
   [FIPS-180-2].

このキー形式を使用した署名と検証は、SHA-1ハッシュ[FIPS-180-2]を使用するデジタル署名標準[FIPS-186-2]に従って行われます。


   The resulting signature is encoded as follows:

結果の署名は次のようにエンコードされます。


      string    "ssh-dss"
      string    dss_signature_blob

   The value for 'dss_signature_blob' is encoded as a string containing
   r, followed by s (which are 160-bit integers, without lengths or
   padding, unsigned, and in network byte order).

'dss_signature_blob'の値は、rの後にsが続く文字列としてエンコードされます(160ビット整数で、長さやパディングなし、符号なし、ネットワークバイト順)。


   The "ssh-rsa" key format has the following specific encoding:

「ssh-rsa」キー形式には、次の固有のエンコーディングがあります。


      string    "ssh-rsa"
      mpint     e
      mpint     n

   Here the 'e' and 'n' parameters form the signature key blob.

ここで、「e」および「n」パラメーターは署名鍵ブロブを形成します。


   Signing and verifying using this key format is performed according to
   the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

この鍵形式を使用した署名と検証は、SHA-1ハッシュを使用して[RFC3447]のRSASSA-PKCS1-v1_5スキームに従って実行されます。


   The resulting signature is encoded as follows:

結果の署名は次のようにエンコードされます。


      string    "ssh-rsa"
      string    rsa_signature_blob

   The value for 'rsa_signature_blob' is encoded as a string containing
   s (which is an integer, without lengths or padding, unsigned, and in
   network byte order).

'rsa_signature_blob'の値は、sを含む文字列としてエンコードされます(これは整数で、長さやパディングなし、符号なし、ネットワークバイト順)。


   The "pgp-sign-rsa" method indicates the certificates, the public key,
   and the signature are in OpenPGP compatible binary format
   ([RFC2440]).  This method indicates that the key is an RSA-key.

「pgp-sign-rsa」メソッドは、証明書、公開鍵、および署名がOpenPGP互換のバイナリ形式([RFC2440])であることを示します。 このメソッドは、鍵がRSA鍵であることを示しています。


   The "pgp-sign-dss" is as above, but indicates that the key is a
   DSS-key.

「pgp-sign-dss」は上記と同じですが、鍵がDSS鍵であることを示しています。


7.  Key Exchange

7.鍵交換


   Key exchange (kex) begins by each side sending name-lists of
   supported algorithms.  Each side has a preferred algorithm in each
   category, and it is assumed that most implementations, at any given
   time, will use the same preferred algorithm.  Each side MAY guess





Ylonen &  Lonvick           Standards Track                    [Page 15]

RFC 4253              SSH Transport Layer Protocol          January 2006


   which algorithm the other side is using, and MAY send an initial key
   exchange packet according to the algorithm, if appropriate for the
   preferred method.

鍵交換(kex)は、サポートされているアルゴリズムの名前リストを送信する両側から始まります。 各サイドには、各カテゴリに優先アルゴリズムがあり、ほとんどの実装では、常に、同じ優先アルゴリズムが使用されると想定されています。 それぞれの側は、もう一方の側が使用しているアルゴリズムを推測することができ(MAY)、優先される方法に適切な場合は、アルゴリズムに従って最初の鍵交換パケットを送信してもよい(MAY)。


   The guess is considered wrong if:

次の場合、推測は間違っていると見なされます。


   o  the kex algorithm and/or the host key algorithm is guessed wrong
      (server and client have different preferred algorithm), or

o kexアルゴリズムまたはホストキーアルゴリズム(あるいはその両方)が誤って推測されている(サーバーとクライアントの優先アルゴリズムが異なる)、または


   o  if any of the other algorithms cannot be agreed upon (the
      procedure is defined below in Section 7.1).

o他のアルゴリズムのいずれかに合意できない場合(手順はセクション7.1で定義されています)。


   Otherwise, the guess is considered to be right, and the
   optimistically sent packet MUST be handled as the first key exchange
   packet.

それ以外の場合、推測は正しいと見なされ、楽観的に送信されたパケットは最初の鍵交換パケットとして処理される必要があります。


   However, if the guess was wrong, and a packet was optimistically sent
   by one or both parties, such packets MUST be ignored (even if the
   error in the guess would not affect the contents of the initial
   packet(s)), and the appropriate side MUST send the correct initial
   packet.

ただし、推測が間違っていて、パケットが一方または両方から楽観的に送信された場合、そのようなパケットは(推測のエラーが最初のパケットの内容に影響しない場合でも)無視する必要があり、適切な サイドは正しい初期パケットを送信する必要があります。


   A key exchange method uses explicit server authentication if the key
   exchange messages include a signature or other proof of the server's
   authenticity.  A key exchange method uses implicit server
   authentication if, in order to prove its authenticity, the server
   also has to prove that it knows the shared secret, K, by sending a
   message and a corresponding MAC that the client can verify.

鍵交換方法は、鍵交換メッセージに署名またはサーバーの信頼性のその他の証明が含まれている場合、明示的なサーバー認証を使用します。 鍵交換方式は、その真正性を証明するために、クライアントが確認できるメッセージと対応するMACを送信することにより、サーバーが共有秘密鍵Kを知っていることを証明する必要がある場合に、暗黙のサーバー認証を使用します。


   The key exchange method defined by this document uses explicit server
   authentication.  However, key exchange methods with implicit server
   authentication MAY be used with this protocol.  After a key exchange
   with implicit server authentication, the client MUST wait for a
   response to its service request message before sending any further
   data.

このドキュメントで定義されているキー交換方法は、明示的なサーバー認証を使用しています。 ただし、暗黙のサーバー認証を使用する鍵交換方式は、このプロトコルで使用される場合があります。 暗黙的なサーバー認証による鍵交換の後、クライアントは、それ以上のデータを送信する前に、サービス要求メッセージへの応答を待機する必要があります。

















Ylonen &  Lonvick           Standards Track                    [Page 16]

RFC 4253              SSH Transport Layer Protocol          January 2006


7.1.  Algorithm Negotiation

7.1。 アルゴリズム交渉


   Key exchange begins by each side sending the following packet:

鍵交換は、両側が次のパケットを送信することから始まります。


      byte         SSH_MSG_KEXINIT
      byte[16]     cookie (random bytes)
      name-list    kex_algorithms
      name-list    server_host_key_algorithms
      name-list    encryption_algorithms_client_to_server
      name-list    encryption_algorithms_server_to_client
      name-list    mac_algorithms_client_to_server
      name-list    mac_algorithms_server_to_client
      name-list    compression_algorithms_client_to_server
      name-list    compression_algorithms_server_to_client
      name-list    languages_client_to_server
      name-list    languages_server_to_client
      boolean      first_kex_packet_follows
      uint32       0 (reserved for future extension)

   Each of the algorithm name-lists MUST be a comma-separated list of
   algorithm names (see Algorithm Naming in [SSH-ARCH] and additional
   information in [SSH-NUMBERS]).  Each supported (allowed) algorithm
   MUST be listed in order of preference, from most to least.

アルゴリズム名リストのそれぞれは、アルゴリズム名のコンマ区切りのリストでなければなりません([SSH-ARCH]のアルゴリズムの命名と[SSH-NUMBERS]の追加情報を参照)。 サポートされている(許可されている)アルゴリズムはそれぞれ、優先順位の高いものから小さいものの順にリストしなければなりません。


   The first algorithm in each name-list MUST be the preferred (guessed)
   algorithm.  Each name-list MUST contain at least one algorithm name.

各名前リストの最初のアルゴリズムは、推奨(推測)アルゴリズムである必要があります。 各名前リストには、少なくとも1つのアルゴリズム名が含まれている必要があります。


      cookie

クッキー

         The 'cookie' MUST be a random value generated by the sender.
         Its purpose is to make it impossible for either side to fully
         determine the keys and the session identifier.

「cookie」は、送信者が生成したランダムな値である必要があります。 その目的は、どちらの側もキーとセッション識別子を完全に決定できないようにすることです。


      kex_algorithms

kex_algorithms

         Key exchange algorithms were defined above.  The first
         algorithm MUST be the preferred (and guessed) algorithm.  If
         both sides make the same guess, that algorithm MUST be used.
         Otherwise, the following algorithm MUST be used to choose a key
         exchange method: Iterate over client's kex algorithms, one at a
         time.  Choose the first algorithm that satisfies the following
         conditions:

鍵交換アルゴリズムは上記で定義されています。 最初のアルゴリズムは、推奨(および推測)アルゴリズムである必要があります。 両方が同じ推測をする場合、そのアルゴリズムを使用しなければなりません。 それ以外の場合は、次のアルゴリズムを使用して鍵交換方法を選択する必要があります:クライアントのkexアルゴリズムを1つずつ繰り返します。 次の条件を満たす最初のアルゴリズムを選択します。


         +  the server also supports the algorithm,

+サーバーはアルゴリズムもサポートし、


         +  if the algorithm requires an encryption-capable host key,
            there is an encryption-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client, and

+アルゴリズムが暗号化対応のホストキーを必要とする場合、クライアントでもサポートされるサーバーのserver_host_key_algorithmsに暗号化対応アルゴリズムがあります。





Ylonen &  Lonvick           Standards Track                    [Page 17]

RFC 4253              SSH Transport Layer Protocol          January 2006


         +  if the algorithm requires a signature-capable host key,
            there is a signature-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client.

+アルゴリズムが署名対応のホスト鍵を必要とする場合、サーバーのserver_host_key_algorithmsに署名対応のアルゴリズムがあり、これもクライアントによってサポートされています。


      If no algorithm satisfying all these conditions can be found, the
      connection fails, and both sides MUST disconnect.

これらすべての条件を満たすアルゴリズムが見つからない場合、接続は失敗し、両側が切断する必要があります。


      server_host_key_algorithms

server_host_key_algorithms

         A name-list of the algorithms supported for the server host
         key.  The server lists the algorithms for which it has host
         keys; the client lists the algorithms that it is willing to
         accept.  There MAY be multiple host keys for a host, possibly
         with different algorithms.

サーバーホストキーでサポートされているアルゴリズムの名前リスト。 サーバーは、ホスト鍵を持つアルゴリズムをリストします。 クライアントは、受け入れることができるアルゴリズムをリストします。 1つのホストに複数のホストキーが存在する可能性があります(アルゴリズムが異なる可能性があります)。


         Some host keys may not support both signatures and encryption
         (this can be determined from the algorithm), and thus not all
         host keys are valid for all key exchange methods.

一部のホスト鍵は、署名と暗号化の両方をサポートしていない場合があります(これはアルゴリズムから判断できます)。したがって、すべてのホスト鍵がすべての鍵交換方式で有効であるとは限りません。


         Algorithm selection depends on whether the chosen key exchange
         algorithm requires a signature or an encryption-capable host
         key.  It MUST be possible to determine this from the public key
         algorithm name.  The first algorithm on the client's name-list
         that satisfies the requirements and is also supported by the
         server MUST be chosen.  If there is no such algorithm, both
         sides MUST disconnect.

アルゴリズムの選択は、選択した鍵交換アルゴリズムに署名が必要か、暗号化対応のホスト鍵が必要かによって異なります。 これは、公開鍵アルゴリズム名から判別できる必要があります。 要件を満たし、サーバーによってもサポートされるクライアントの名前リストの最初のアルゴリズムを選択する必要があります。 そのようなアルゴリズムがない場合は、両側を切断する必要があります。


      encryption_algorithms

encryption_algorithms

         A name-list of acceptable symmetric encryption algorithms (also
         known as ciphers) in order of preference.  The chosen
         encryption algorithm to each direction MUST be the first
         algorithm on the client's name-list that is also on the
         server's name-list.  If there is no such algorithm, both sides
         MUST disconnect.

受け入れ可能な対称暗号化アルゴリズム(暗号とも呼ばれます)の優先順の名前リスト。 各方向に選択された暗号化アルゴリズムは、サーバーの名前リストにもあるクライアントの名前リストの最初のアルゴリズムでなければなりません。 そのようなアルゴリズムがない場合は、両側を切断する必要があります。


         Note that "none" must be explicitly listed if it is to be
         acceptable.  The defined algorithm names are listed in Section
         6.3.

許容できる場合は、「none」を明示的にリストする必要があることに注意してください。 定義されたアルゴリズム名はセクション6.3にリストされています。


      mac_algorithms

mac_algorithms

         A name-list of acceptable MAC algorithms in order of
         preference.  The chosen MAC algorithm MUST be the first
         algorithm on the client's name-list that is also on the
         server's name-list.  If there is no such algorithm, both sides
         MUST disconnect.

受け入れ可能なMACアルゴリズムの名前リスト。 選択されたMACアルゴリズムは、サーバーの名前リストにもあるクライアントの名前リストの最初のアルゴリズムである必要があります。 そのようなアルゴリズムがない場合は、両側を切断する必要があります。


         Note that "none" must be explicitly listed if it is to be
         acceptable.  The MAC algorithm names are listed in Section 6.4.

許容できる場合は、「none」を明示的にリストする必要があることに注意してください。 MACアルゴリズム名はセクション6.4にリストされています。




Ylonen &  Lonvick           Standards Track                    [Page 18]

RFC 4253              SSH Transport Layer Protocol          January 2006


      compression_algorithms

compression_algorithms

         A name-list of acceptable compression algorithms in order of
         preference.  The chosen compression algorithm MUST be the first
         algorithm on the client's name-list that is also on the
         server's name-list.  If there is no such algorithm, both sides
         MUST disconnect.

受け入れ可能な圧縮アルゴリズムの名前リスト。 選択した圧縮アルゴリズムは、サーバーの名前リストにもあるクライアントの名前リストの最初のアルゴリズムでなければなりません。 そのようなアルゴリズムがない場合は、両側を切断する必要があります。


         Note that "none" must be explicitly listed if it is to be
         acceptable.  The compression algorithm names are listed in
         Section 6.2.

許容できる場合は、「none」を明示的にリストする必要があることに注意してください。 圧縮アルゴリズム名はセクション6.2にリストされています。


      languages

languages

         This is a name-list of language tags in order of preference
         [RFC3066].  Both parties MAY ignore this name-list.  If there
         are no language preferences, this name-list SHOULD be empty as
         defined in Section 5 of [SSH-ARCH].  Language tags SHOULD NOT
         be present unless they are known to be needed by the sending
         party.

これは、優先順位の言語タグの名前リストです[RFC3066]。 両当事者は、この名前リストを無視してもよい(MAY)。 言語設定がない場合、この名前リストは[SSH-ARCH]のセクション5で定義されているように空である必要があります。 言語タグは、送信側で必要であることがわかっている場合を除き、存在してはなりません。


      first_kex_packet_follows

first_kex_packet_follows

         Indicates whether a guessed key exchange packet follows.  If a
         guessed packet will be sent, this MUST be TRUE.  If no guessed
         packet will be sent, this MUST be FALSE.

推測された鍵交換パケットが続くかどうかを示します。 推測されたパケットが送信される場合、これは真でなければなりません。 推測されたパケットが送信されない場合、これはFALSEでなければなりません。


         After receiving the SSH_MSG_KEXINIT packet from the other side,
         each party will know whether their guess was right.  If the
         other party's guess was wrong, and this field was TRUE, the
         next packet MUST be silently ignored, and both sides MUST then
         act as determined by the negotiated key exchange method.  If
         the guess was right, key exchange MUST continue using the
         guessed packet.

相手側からSSH_MSG_KEXINITパケットを受信すると、各パーティは自分の推測が正しいかどうかを知ることができます。 相手の推測が間違っていて、このフィールドがTRUEである場合、次のパケットは黙って無視されなければならず(MUST)、両側は交渉された鍵交換方法によって決定されたとおりに動作しなければなりません(MUST)。 推測が正しかった場合、鍵交換は推測されたパケットを引き続き使用しなければなりません(MUST)。


   After the SSH_MSG_KEXINIT message exchange, the key exchange
   algorithm is run.  It may involve several packet exchanges, as
   specified by the key exchange method.

SSH_MSG_KEXINITメッセージ交換の後、鍵交換アルゴリズムが実行されます。 鍵交換方法で指定されているように、いくつかのパケット交換が必要になる場合があります。


   Once a party has sent a SSH_MSG_KEXINIT message for key exchange or
   re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section
   7.3), it MUST NOT send any messages other than:

パーティが鍵交換または再交換のためにSSH_MSG_KEXINITメッセージを送信すると、SSH_MSG_NEWKEYSメッセージ(セクション7.3)を送信するまで、以下以外のメッセージを送信してはなりません(MUST NOT)。


   o  Transport layer generic messages (1 to 19) (but
      SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT MUST NOT be
      sent);

oトランスポート層の汎用メッセージ(1〜19)(ただし、SSH_MSG_SERVICE_REQUESTおよびSSH_MSG_SERVICE_ACCEPTを送信してはなりません)。


   o  Algorithm negotiation messages (20 to 29) (but further
      SSH_MSG_KEXINIT messages MUST NOT be sent);

oアルゴリズムネゴシエーションメッセージ(20〜29)(ただし、さらにSSH_MSG_KEXINITメッセージを送信してはなりません)。


   o  Specific key exchange method messages (30 to 49).

o特定の鍵交換方法のメッセージ(30から49)。




Ylonen &  Lonvick           Standards Track                    [Page 19]

RFC 4253              SSH Transport Layer Protocol          January 2006


   The provisions of Section 11 apply to unrecognized messages.

セクション11の規定は、認識されないメッセージに適用されます。


   Note, however, that during a key re-exchange, after sending a
   SSH_MSG_KEXINIT message, each party MUST be prepared to process an
   arbitrary number of messages that may be in-flight before receiving a
   SSH_MSG_KEXINIT message from the other party.

ただし、鍵の再交換中は、SSH_MSG_KEXINITメッセージを送信した後、各パーティは、他のパーティからのSSH_MSG_KEXINITメッセージを受信する前に、処理中の可能性がある任意の数のメッセージを処理できるように準備する必要があります。


7.2.  Output from Key Exchange

7.2。 鍵交換からの出力


   The key exchange produces two values: a shared secret K, and an
   exchange hash H.  Encryption and authentication keys are derived from
   these.  The exchange hash H from the first key exchange is
   additionally used as the session identifier, which is a unique
   identifier for this connection.  It is used by authentication methods
   as a part of the data that is signed as a proof of possession of a
   private key.  Once computed, the session identifier is not changed,
   even if keys are later re-exchanged.

鍵交換により、共有秘密Kと交換ハッシュHという2つの値が生成されます。 暗号化および認証キーはこれらから派生します。 最初の鍵交換からの交換ハッシュHは、この接続の一意の識別子であるセッション識別子としてさらに使用されます。 認証方式では、秘密鍵の所持の証明として署名されるデータの一部として使用されます。 いったん計算されると、後でキーが再交換されても、セッション識別子は変更されません。


   Each key exchange method specifies a hash function that is used in
   the key exchange.  The same hash algorithm MUST be used in key
   derivation.  Here, we'll call it HASH.

各鍵交換方式は、鍵交換で使用されるハッシュ関数を指定します。 同じハッシュアルゴリズムをキーの派生で使用する必要があります。 ここでは、HASHと呼びます。


   Encryption keys MUST be computed as HASH, of a known value and K, as
   follows:

暗号化キーは、次のように既知の値とKのハッシュとして計算する必要があります。


   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data.  "A" means the single character A, ASCII 65).

oサーバーへの最初のIVクライアント:HASH(K || H || "A" || session_id)(ここで、Kはmpintとしてエンコードされ、 "A"はバイトとしてエンコードされ、session_idは生データとしてエンコードされます。 「A」は、単一文字A、ASCII 65)を意味します。


   o  Initial IV server to client: HASH(K || H || "B" || session_id)

o最初のIVサーバーからクライアントへ:HASH(K || H || "B" || session_id)


   o  Encryption key client to server: HASH(K || H || "C" || session_id)

oサーバーへの暗号化キークライアント:HASH(K || H || "C" || session_id)


   o  Encryption key server to client: HASH(K || H || "D" || session_id)

oクライアントへの暗号化キーサーバー:HASH(K || H || "D" || session_id)


   o  Integrity key client to server: HASH(K || H || "E" || session_id)

oサーバーへの整合性キークライアント:HASH(K || H || "E" || session_id)


   o  Integrity key server to client: HASH(K || H || "F" || session_id)

oクライアントへの整合性キーサーバー:HASH(K || H || "F" || session_id)


   Key data MUST be taken from the beginning of the hash output.  As
   many bytes as needed are taken from the beginning of the hash value.
   If the key length needed is longer than the output of the HASH, the
   key is extended by computing HASH of the concatenation of K and H and
   the entire key so far, and appending the resulting bytes (as many as
   HASH generates) to the key.  This process is repeated until enough
   key material is available; the key is taken from the beginning of
   this value.  In other words:

キーデータは、ハッシュ出力の最初から取得する必要があります。 必要な数のバイトがハッシュ値の先頭から取得されます。 必要なキーの長さがHASHの出力よりも長い場合、KとHの連結のHASHとこれまでのキー全体のHASHを計算し、結果のバイト(HASHが生成したものと同じ)をキーに追加することにより、キーが拡張されます。 。 このプロセスは、十分なキーマテリアルが利用可能になるまで繰り返されます。 キーはこの値の最初から取得されます。 言い換えると:





Ylonen &  Lonvick           Standards Track                    [Page 20]

RFC 4253              SSH Transport Layer Protocol          January 2006


      K1 = HASH(K || H || X || session_id)   (X is e.g., "A")
      K2 = HASH(K || H || K1)
      K3 = HASH(K || H || K1 || K2)
      ...
      key = K1 || K2 || K3 || ...

   This process will lose entropy if the amount of entropy in K is
   larger than the internal state size of HASH.

Kのエントロピーの量がHASHの内部状態サイズよりも大きい場合、このプロセスはエントロピーを失います。


7.3.  Taking Keys Into Use

7.3。 キーを使用する


   Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
   This message is sent with the old keys and algorithms.  All messages
   sent after this message MUST use the new keys and algorithms.

鍵交換は、SSH_MSG_NEWKEYSメッセージを送信する両側で終了します。 このメッセージは、古い鍵とアルゴリズムで送信されます。 このメッセージの後に送信されるすべてのメッセージは、新しいキーとアルゴリズムを使用する必要があります。


   When this message is received, the new keys and algorithms MUST be
   used for receiving.

このメッセージが受信された場合、受信には新しいキーとアルゴリズムを使用する必要があります。


   The purpose of this message is to ensure that a party is able to
   respond with an SSH_MSG_DISCONNECT message that the other party can
   understand if something goes wrong with the key exchange.

このメッセージの目的は、ある当事者がSSH_MSG_DISCONNECTメッセージで応答できることを保証することです。このメッセージは、鍵交換で問題が発生した場合に相手が理解できるようにするためです。


      byte      SSH_MSG_NEWKEYS

8.  Diffie-Hellman Key Exchange

8. Diffie-Hellman鍵交換


   The Diffie-Hellman (DH) key exchange provides a shared secret that
   cannot be determined by either party alone.  The key exchange is
   combined with a signature with the host key to provide host
   authentication.  This key exchange method provides explicit server
   authentication as defined in Section 7.

Diffie-Hellman(DH)鍵交換は、どちらの当事者も単独では決定できない共有秘密を提供します。 鍵交換は、ホスト認証を提供するためにホスト鍵を含む署名と組み合わされます。 この鍵交換方式は、セクション7で定義されているように、明示的なサーバー認証を提供します。


   The following steps are used to exchange a key.  In this, C is the
   client; S is the server; p is a large safe prime; g is a generator
   for a subgroup of GF(p); q is the order of the subgroup; V_S is S's
   identification string; V_C is C's identification string; K_S is S's
   public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's
   SSH_MSG_KEXINIT message that have been exchanged before this part
   begins.

次の手順を使用して、キーを交換します。 この場合、Cはクライアントです。 Sはサーバーです。 pは大きな安全な素数です。 gはGF(p)のサブグループのジェネレーターです。 qはサブグループの次数です。 V_SはSの識別文字列です。 V_CはCの識別文字列です。 K_SはSの公開ホストキーです。 I_CはCのSSH_MSG_KEXINITメッセージで、I_SはSのSSH_MSG_KEXINITメッセージで、この部分が始まる前に交換されています。


   1. C generates a random number x (1 < x < q) and computes
      e = g^x mod p.  C sends e to S.

1.Cは乱数x(1 <x <q)を生成し、e = g ^ x mod pを計算します。 CはeをSに送信します。










Ylonen &  Lonvick           Standards Track                    [Page 21]

RFC 4253              SSH Transport Layer Protocol          January 2006


   2. S generates a random number y (0 < y < q) and computes
      f = g^y mod p.  S receives e.  It computes K = e^y mod p,
      H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
      (these elements are encoded according to their types; see below),
      and signature s on H with its private host key.  S sends
      (K_S || f || s) to C.  The signing operation may involve a
      second hashing operation.

2. Sは乱数y(0 <y <q)を生成し、f = g ^ y mod pを計算します。 Sはeを受信します。 K = e ^ y mod p、H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)を計算します(これらの要素はそのタイプに従ってエンコードされます。以下を参照してください) 、およびHの署名sとそのプライベートホストキー。 Sは(K_S || f || s)をCに送信します。 署名操作には、2番目のハッシュ操作が含まれる場合があります。


   3. C verifies that K_S really is the host key for S (e.g., using
      certificates or a local database).  C is also allowed to accept
      the key without verification; however, doing so will render the
      protocol insecure against active attacks (but may be desirable for
      practical reasons in the short term in many environments).  C then
      computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S
      || e || f || K), and verifies the signature s on H.

3. Cは、K_SがSのホストキーであることを確認します(たとえば、証明書またはローカルデータベースを使用)。 Cは、検証なしでキーを受け入れることもできます。 ただし、これを行うと、プロトコルがアクティブな攻撃に対して安全でなくなります(ただし、多くの環境では、短期的には実用上の理由から望ましい場合があります)。 次に、CはK = f ^ x mod p、H =ハッシュ(V_C || V_S || I_C || I_S || K_S || e || f || K)を計算し、Hの署名sを検証します。


   Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be
   sent or accepted by either side.  If this condition is violated, the
   key exchange fails.

[1、p-1]の範囲にない「e」または「f」の値は、どちらの側からも送信または受け入れてはなりません。 この条件に違反すると、鍵の交換が失敗します。


   This is implemented with the following messages.  The hash algorithm
   for computing the exchange hash is defined by the method name, and is
   called HASH.  The public key algorithm for signing is negotiated with
   the SSH_MSG_KEXINIT messages.

これは、次のメッセージで実装されます。 交換ハッシュを計算するためのハッシュアルゴリズムはメソッド名で定義され、HASHと呼ばれます。 署名用の公開鍵アルゴリズムは、SSH_MSG_KEXINITメッセージでネゴシエートされます。


   First, the client sends the following:

まず、クライアントは以下を送信します。


      byte      SSH_MSG_KEXDH_INIT
      mpint     e
      byte      SSH_MSG_KEXDH_INIT
      mpint     e

   The server then responds with the following:

その後、サーバーは次のように応答します。


      byte      SSH_MSG_KEXDH_REPLY
      string    server public host key and certificates (K_S)
      mpint     f
      string    signature of H
      byte      SSH_MSG_KEXDH_REPLY
      string    サーバーのパブリックホストキーと証明書(K_S)
      mpint     f
      string    Hの署名















Ylonen &  Lonvick           Standards Track                    [Page 22]

RFC 4253              SSH Transport Layer Protocol          January 2006


   The hash H is computed as the HASH hash of the concatenation of the
   following:

ハッシュHは、次の連結のHASHハッシュとして計算されます。


      string    V_C, the client's identification string (CR and LF
                excluded)
      string    V_S, the server's identification string (CR and LF
                excluded)
      string    I_C, the payload of the client's SSH_MSG_KEXINIT
      string    I_S, the payload of the server's SSH_MSG_KEXINIT
      string    K_S, the host key
      mpint     e, exchange value sent by the client
      mpint     f, exchange value sent by the server
      mpint     K, the shared secret
      string    V_C、クライアントの識別文字列(CRおよびLFを除く)
      string    V_S、サーバーの識別文字列(CRおよびLFを除く)
      string    I_C、クライアントのSSH_MSG_KEXINITのペイロード
      string    I_S、サーバーのSSH_MSG_KEXINITのペイロード
      string    K_S、ホストキー
      mpint     e、クライアントから送信された価値の交換
      mpint     f、サーバーから送信された価値の交換
      mpint     K、共有秘密

   This value is called the exchange hash, and it is used to
   authenticate the key exchange.  The exchange hash SHOULD be kept
   secret.

この値は交換ハッシュと呼ばれ、鍵交換の認証に使用されます。 交換ハッシュは秘密にしてください。


   The signature algorithm MUST be applied over H, not the original
   data.  Most signature algorithms include hashing and additional
   padding (e.g., "ssh-dss" specifies SHA-1 hashing).  In that case, the
   data is first hashed with HASH to compute H, and H is then hashed
   with SHA-1 as part of the signing operation.

署名アルゴリズムは、元のデータではなく、Hに適用する必要があります。 ほとんどの署名アルゴリズムには、ハッシュと追加のパディングが含まれます(たとえば、「ssh-dss」はSHA-1ハッシュを指定します)。 その場合、データはまずHASHでハッシュされてHが計算され、次にHは署名操作の一部としてSHA-1でハッシュされます。


8.1.  diffie-hellman-group1-sha1

8.1。 diffie-hellman-group1-sha1


   The "diffie-hellman-group1-sha1" method specifies the Diffie-Hellman
   key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024-
   bit MODP Group).  This method MUST be supported for interoperability
   as all of the known implementations currently support it.  Note that
   this method is named using the phrase "group1", even though it
   specifies the use of Oakley Group 2.

「diffie-hellman-group1-sha1」方式は、SHA-1とのDiffie-Hellman鍵交換をHASHとして指定し、Oakley Group 2 [RFC2409](1024ビットMODPグループ)を指定します。 このメソッドは、既知の実装のすべてが現在サポートしているため、相互運用性をサポートする必要があります。 このメソッドは、Oakley Group 2の使用を指定しているにもかかわらず、「group1」というフレーズを使用して名前が付けられていることに注意してください。


8.2.  diffie-hellman-group14-sha1

8.2。 diffie-hellman-group14-sha1


   The "diffie-hellman-group14-sha1" method specifies a Diffie-Hellman
   key exchange with SHA-1 as HASH and Oakley Group 14 [RFC3526] (2048-
   bit MODP Group), and it MUST also be supported.

「diffie-hellman-group14-sha1」メソッドは、SHA-1とのDiffie-Hellman鍵交換をHASHおよびOakley Group 14 [RFC3526](2048ビットMODPグループ)として指定し、これもサポートする必要があります。


9.  Key Re-Exchange

9.キーの再交換


   Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
   not already doing a key exchange (as described in Section 7.1).  When
   this message is received, a party MUST respond with its own
   SSH_MSG_KEXINIT message, except when the received SSH_MSG_KEXINIT
   already was a reply.  Either party MAY initiate the re-exchange, but
   roles MUST NOT be changed (i.e., the server remains the server, and
   the client remains the client).

キーの再交換は、キーの交換がまだ行われていない場合(セクション7.1で説明)、SSH_MSG_KEXINITパケットを送信することによって開始されます。 このメッセージが受信された場合、受信者は、受信したSSH_MSG_KEXINITがすでに応答である場合を除き、独自のSSH_MSG_KEXINITメッセージで応答する必要があります。 どちらの当事者も再交換を開始できますが、役割を変更してはなりません(つまり、サーバーはサーバーのままで、クライアントはクライアントのままです)。




Ylonen &  Lonvick           Standards Track                    [Page 23]

RFC 4253              SSH Transport Layer Protocol          January 2006


   Key re-exchange is performed using whatever encryption was in effect
   when the exchange was started.  Encryption, compression, and MAC
   methods are not changed before a new SSH_MSG_NEWKEYS is sent after
   the key exchange (as in the initial key exchange).  Re-exchange is
   processed identically to the initial key exchange, except for the
   session identifier that will remain unchanged.  It is permissible to
   change some or all of the algorithms during the re-exchange.  Host
   keys can also change.  All keys and initialization vectors are
   recomputed after the exchange.  Compression and encryption contexts
   are reset.

キーの再交換は、交換の開始時に有効だった暗号化を使用して実行されます。 暗号化、圧縮、およびMACメソッドは、(最初のキー交換のように)キー交換後に新しいSSH_MSG_NEWKEYSが送信されるまで変更されません。 再交換は、変更されないままになるセッションIDを除いて、最初の鍵交換と同じように処理されます。 再交換中にアルゴリズムの一部またはすべてを変更することは許容されます。 ホストキーも変更できます。 すべてのキーと初期化ベクトルは、交換後に再計算されます。 圧縮と暗号化のコンテキストがリセットされます。


   It is RECOMMENDED that the keys be changed after each gigabyte of
   transmitted data or after each hour of connection time, whichever
   comes sooner.  However, since the re-exchange is a public key
   operation, it requires a fair amount of processing power and should
   not be performed too often.

送信データの1ギガバイトごと、または接続時間の1時間ごとのいずれか早い方の後でキーを変更することをお勧めします。 ただし、再交換は公開鍵操作であるため、かなりの処理能力が必要であり、あまり頻繁に実行しないでください。


   More application data may be sent after the SSH_MSG_NEWKEYS packet
   has been sent; key exchange does not affect the protocols that lie
   above the SSH transport layer.

SSH_MSG_NEWKEYSパケットが送信された後、さらに多くのアプリケーションデータが送信される場合があります。 鍵交換は、SSHトランスポート層の上にあるプロトコルには影響しません。


10.  Service Request

10.サービスリクエスト


   After the key exchange, the client requests a service.  The service
   is identified by a name.  The format of names and procedures for
   defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS].

鍵交換後、クライアントはサービスを要求します。 サービスは名前で識別されます。 名前の形式と新しい名前を定義する手順は、[SSH-ARCH]と[SSH-NUMBERS]で定義されています。


   Currently, the following names have been reserved:

現在、次の名前が予約されています。


      ssh-userauth
      ssh-connection

   Similar local naming policy is applied to the service names, as is
   applied to the algorithm names.  A local service should use the
   PRIVATE USE syntax of "servicename@domain".

アルゴリズム名に適用されるのと同様のローカル命名ポリシーがサービス名に適用されます。 ローカルサービスは、「servicename @ domain」のPRIVATE USE構文を使用する必要があります。


      byte      SSH_MSG_SERVICE_REQUEST
      string    service name
      byte      SSH_MSG_SERVICE_REQUEST
      string    サービス名

   If the server rejects the service request, it SHOULD send an
   appropriate SSH_MSG_DISCONNECT message and MUST disconnect.

サーバーがサービス要求を拒否した場合、サーバーは適切なSSH_MSG_DISCONNECTメッセージを送信して、切断する必要があります(SHOULD)。


   When the service starts, it may have access to the session identifier
   generated during the key exchange.

サービスが開始すると、キー交換中に生成されたセッション識別子にアクセスできます。








Ylonen &  Lonvick           Standards Track                    [Page 24]

RFC 4253              SSH Transport Layer Protocol          January 2006


   If the server supports the service (and permits the client to use
   it), it MUST respond with the following:

サーバーがサービスをサポートする(そしてクライアントがそれを使用することを許可する)場合、サーバーは以下で応答しなければなりません:


      byte      SSH_MSG_SERVICE_ACCEPT
      string    service name
      byte      SSH_MSG_SERVICE_ACCEPT
      string    サービス名

   Message numbers used by services should be in the area reserved for
   them (see [SSH-ARCH] and [SSH-NUMBERS]).  The transport level will
   continue to process its own messages.

サービスが使用するメッセージ番号は、それらのために予約された領域にある必要があります([SSH-ARCH]および[SSH-NUMBERS]を参照)。 トランスポートレベルは、独自のメッセージを処理し続けます。


   Note that after a key exchange with implicit server authentication,
   the client MUST wait for a response to its service request message
   before sending any further data.

暗黙のサーバー認証による鍵交換の後、クライアントはそれ以上のデータを送信する前に、サービス要求メッセージへの応答を待たなければならないことに注意してください。


11.  Additional Messages

11.追加メッセージ


   Either party may send any of the following messages at any time.

いずれの当事者も、次のメッセージをいつでも送信できます。


11.1.  Disconnection Message

11.1 切断メッセージ


      byte      SSH_MSG_DISCONNECT
      uint32    reason code
      string    description in ISO-10646 UTF-8 encoding [RFC3629]
      string    language tag [RFC3066]
      byte      SSH_MSG_DISCONNECT
      uint32    理由コード
      string    ISO-10646 UTF-8エンコーディングの記述[RFC3629]
      string    言語タグ[RFC3066]

   This message causes immediate termination of the connection.  All
   implementations MUST be able to process this message; they SHOULD be
   able to send this message.

このメッセージにより、接続が即座に終了します。 すべての実装はこのメッセージを処理できなければなりません。 彼らはこのメッセージを送ることができるべきです。


   The sender MUST NOT send or receive any data after this message, and
   the recipient MUST NOT accept any data after receiving this message.
   The Disconnection Message 'description' string gives a more specific
   explanation in a human-readable form.  The Disconnection Message
   'reason code' gives the reason in a more machine-readable format
   (suitable for localization), and can have the values as displayed in
   the table below.  Note that the decimal representation is displayed
   in this table for readability, but the values are actually uint32
   values.

送信者はこのメッセージの後にデータを送信または受信してはならず(MUST NOT)、受信者はこのメッセージの受信後にデータを受け入れてはなりません(MUST NOT)。 切断メッセージの「説明」文字列は、人間が読める形式でより具体的な説明を提供します。 切断メッセージの「理由コード」は、より機械で読み取り可能な形式(ローカリゼーションに適した形式)で理由を示し、以下の表に表示されている値を持つことができます。 この表では、読みやすくするために10進数表記を表示していますが、実際の値はuint32値です。














Ylonen &  Lonvick           Standards Track                    [Page 25]

RFC 4253              SSH Transport Layer Protocol          January 2006


           Symbolic name                                reason code
           -------------                                -----------
      SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT             1
      SSH_DISCONNECT_PROTOCOL_ERROR                          2
      SSH_DISCONNECT_KEY_EXCHANGE_FAILED                     3
      SSH_DISCONNECT_RESERVED                                4
      SSH_DISCONNECT_MAC_ERROR                               5
      SSH_DISCONNECT_COMPRESSION_ERROR                       6
      SSH_DISCONNECT_SERVICE_NOT_AVAILABLE                   7
      SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED          8
      SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE                 9
      SSH_DISCONNECT_CONNECTION_LOST                        10
      SSH_DISCONNECT_BY_APPLICATION                         11
      SSH_DISCONNECT_TOO_MANY_CONNECTIONS                   12
      SSH_DISCONNECT_AUTH_CANCELLED_BY_USER                 13
      SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE         14
      SSH_DISCONNECT_ILLEGAL_USER_NAME                      15

   If the 'description' string is displayed, the control character
   filtering discussed in [SSH-ARCH] should be used to avoid attacks by
   sending terminal control characters.

「説明」文字列が表示される場合、[SSH-ARCH]で説明されている制御文字フィルタリングを使用して、端末制御文字を送信することによる攻撃を回避する必要があります。


   Requests for assignments of new Disconnection Message 'reason code'
   values (and associated 'description' text) in the range of 0x00000010
   to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
   described in [RFC2434].  The Disconnection Message 'reason code'
   values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for
   PRIVATE USE.  As noted, the actual instructions to the IANA are in
   [SSH-NUMBERS].

[RFC2434]で説明されているように、0x00000010から0xFDFFFFFFの範囲の新しい切断メッセージ「理由コード」値(および関連する「説明」テキスト)の割り当てのリクエストは、IETF CONSENSUSメソッドを介して実行する必要があります。 0xFE000000から0xFFFFFFFFの範囲の切断メッセージ「理由コード」の値は、プライベートな使用のために予約されています。 前述のとおり、IANAへの実際の指示は[SSH-NUMBERS]にあります。


11.2.  Ignored Data Message

11.2 無視されたデータメッセージ


      byte      SSH_MSG_IGNORE
      string    data
      byte      SSH_MSG_IGNORE
      string    データ

   All implementations MUST understand (and ignore) this message at any
   time (after receiving the identification string).  No implementation
   is required to send them.  This message can be used as an additional
   protection measure against advanced traffic analysis techniques.

すべての実装は、いつでも(識別文字列を受け取った後)このメッセージを理解(および無視)する必要があります。 それらを送信するための実装は必要ありません。 このメッセージは、高度なトラフィック分析手法に対する追加の保護手段として使用できます。


11.3.  Debug Message

11.3。 デバッグメッセージ


      byte      SSH_MSG_DEBUG
      boolean   always_display
      string    message in ISO-10646 UTF-8 encoding [RFC3629]
      string    language tag [RFC3066]
      byte      SSH_MSG_DEBUG
      boolean   always_display
      string    ISO-10646 UTF-8エンコーディングのメッセージ[RFC3629]
      string    言語タグ[RFC3066]





Ylonen &  Lonvick           Standards Track                    [Page 26]

RFC 4253              SSH Transport Layer Protocol          January 2006


   All implementations MUST understand this message, but they are
   allowed to ignore it.  This message is used to transmit information
   that may help debugging.  If 'always_display' is TRUE, the message
   SHOULD be displayed.  Otherwise, it SHOULD NOT be displayed unless
   debugging information has been explicitly requested by the user.

すべての実装はこのメッセージを理解する必要がありますが、無視することが許可されています。 このメッセージは、デバッグに役立つ情報を送信するために使用されます。 「always_display」がTRUEの場合、メッセージを表示する必要があります(SHOULD)。 それ以外の場合は、ユーザーがデバッグ情報を明示的に要求しない限り、表示しないでください。


   The 'message' doesn't need to contain a newline.  It is, however,
   allowed to consist of multiple lines separated by CRLF (Carriage
   Return - Line Feed) pairs.

「メッセージ」には改行を含める必要はありません。 ただし、CRLF(改行-改行)のペアで区切られた複数の行で構成することはできます。


   If the 'message' string is displayed, the terminal control character
   filtering discussed in [SSH-ARCH] should be used to avoid attacks by
   sending terminal control characters.

「メッセージ」文字列が表示される場合、[SSH-ARCH]で説明されている端末制御文字フィルタリングを使用して、端末制御文字を送信することによる攻撃を回避する必要があります。


11.4.  Reserved Messages

11.4。 予約済みメッセージ


   An implementation MUST respond to all unrecognized messages with an
   SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
   received.  Such messages MUST be otherwise ignored.  Later protocol
   versions may define other meanings for these message types.

実装は、メッセージが受信された順序でSSH_MSG_UNIMPLEMENTEDメッセージを使用して、認識されないすべてのメッセージに応答する必要があります。 そうでなければ、そのようなメッセージは無視されなければなりません。 以降のプロトコルバージョンでは、これらのメッセージタイプの他の意味が定義されている場合があります。


      byte      SSH_MSG_UNIMPLEMENTED
      uint32    packet sequence number of rejected message
      byte      SSH_MSG_UNIMPLEMENTED
      uint32    拒否されたメッセージのパケットシーケンス番号

12.  Summary of Message Numbers

12.メッセージ番号の要約


   The following is a summary of messages and their associated message
   number.

以下は、メッセージとそれに関連するメッセージ番号の要約です。


         SSH_MSG_DISCONNECT             1
         SSH_MSG_IGNORE                 2
         SSH_MSG_UNIMPLEMENTED          3
         SSH_MSG_DEBUG                  4
         SSH_MSG_SERVICE_REQUEST        5
         SSH_MSG_SERVICE_ACCEPT         6
         SSH_MSG_KEXINIT                20
         SSH_MSG_NEWKEYS                21

   Note that numbers 30-49 are used for kex packets.  Different kex
   methods may reuse message numbers in this range.

番号30~49はkexパケットに使用されることに注意してください。 さまざまなkexメソッドがこの範囲のメッセージ番号を再利用する場合があります。


13.  IANA Considerations

13. IANAに関する考慮事項


   This document is part of a set.  The IANA considerations for the SSH
   protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and
   this document, are detailed in [SSH-NUMBERS].

このドキュメントはセットの一部です。 [SSH-ARCH]、[SSH-USERAUTH]、[SSH-CONNECT]、およびこのドキュメントで定義されているSSHプロトコルに関するIANAの考慮事項は、[SSH-NUMBERS]で詳しく説明されています。






Ylonen &  Lonvick           Standards Track                    [Page 27]

RFC 4253              SSH Transport Layer Protocol          January 2006


14.  Security Considerations

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


   This protocol provides a secure encrypted channel over an insecure
   network.  It performs server host authentication, key exchange,
   encryption, and integrity protection.  It also derives a unique
   session ID that may be used by higher-level protocols.

このプロトコルは、安全でないネットワーク上で安全な暗号化チャネルを提供します。 サーバーホスト認証、キー交換、暗号化、整合性保護を実行します。 また、上位レベルのプロトコルで使用できる一意のセッションIDも取得します。


   Full security considerations for this protocol are provided in
   [SSH-ARCH].

このプロトコルの完全なセキュリティの考慮事項は、[SSH-ARCH]で提供されています。











































Ylonen &  Lonvick           Standards Track                    [Page 28]

RFC 4253              SSH Transport Layer Protocol          January 2006


15.  References

15.リファレンス


15.1.  Normative References

15.1。 規範的な参考文献


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

   [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
                  (SSH) Authentication Protocol", RFC 4252, January
                  2006.

   [SSH-CONNECT]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
                  (SSH) Connection Protocol", RFC 4254, January 2006.

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

   [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
                  1321, April 1992.

   [RFC1950]      Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                  Format Specification version 3.3", RFC 1950, May 1996.

   [RFC1951]      Deutsch, P., "DEFLATE Compressed Data Format
                  Specification version 1.3", RFC 1951, May 1996.

   [RFC2104]      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2144]      Adams, C., "The CAST-128 Encryption Algorithm", RFC
                  2144, May 1997.

   [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC 2409, November 1998.

   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  2434, October 1998.

   [RFC2440]      Callas, J., Donnerhacke, L., Finney, H., and R.
                  Thayer, "OpenPGP Message Format", RFC 2440, November
                  1998.




Ylonen &  Lonvick           Standards Track                    [Page 29]

RFC 4253              SSH Transport Layer Protocol          January 2006


   [RFC3066]      Alvestrand, H., "Tags for the Identification of
                  Languages", BCP 47, RFC 3066, January 2001.

   [RFC3447]      Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                  Standards (PKCS) #1: RSA Cryptography Specifications
                  Version 2.1", RFC 3447, February 2003.

   [RFC3526]      Kivinen, T. and M. Kojo, "More Modular Exponential
                  (MODP) Diffie-Hellman groups for Internet Key Exchange
                  (IKE)", RFC 3526, May 2003.

   [RFC3629]      Yergeau, F., "UTF-8, a transformation format of ISO
                  10646", STD 63, RFC 3629, November 2003.

   [FIPS-180-2]   US National Institute of Standards and Technology,
                  "Secure Hash Standard (SHS)", Federal Information
                  Processing Standards Publication 180-2, August 2002.

   [FIPS-186-2]   US National Institute of Standards and Technology,
                  "Digital Signature Standard (DSS)", Federal
                  Information Processing Standards Publication 186-2,
                  January 2000.

   [FIPS-197]     US National Institute of Standards and Technology,
                  "Advanced Encryption Standard (AES)", Federal
                  Information Processing Standards Publication 197,
                  November 2001.

   [FIPS-46-3]    US National Institute of Standards and Technology,
                  "Data Encryption Standard (DES)", Federal Information
                  Processing Standards Publication 46-3, October 1999.

   [SCHNEIER]     Schneier, B., "Applied Cryptography Second Edition:
                  protocols algorithms and source in code in C", John
                  Wiley and Sons, New York, NY, 1996.

   [TWOFISH]      Schneier, B., "The Twofish Encryptions Algorithm: A
                  128-Bit Block Cipher, 1st Edition", March 1999.

15.2.  Informative References

15.2。 参考情報


   [RFC0894]      Hornig, C., "Standard for the transmission of IP
                  datagrams over Ethernet networks", STD 41, RFC 894,
                  April 1984.

   [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)", STD
                  51, RFC 1661, July 1994.




Ylonen &  Lonvick           Standards Track                    [Page 30]

RFC 4253              SSH Transport Layer Protocol          January 2006


   [RFC2412]      Orman, H., "The OAKLEY Key Determination Protocol",
                  RFC 2412, November 1998.

   [ssh-1.2.30]   Ylonen, T., "ssh-1.2.30/RFC", File within compressed
                  tarball ftp://ftp.funet.fi/pub/unix/security/
                  login/ssh/ssh-1.2.30.tar.gz, November 1995.

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 31]

RFC 4253              SSH Transport Layer 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 32]