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]