[要約] RFC 4253は、セキュアシェル（SSH）トランスポート層プロトコルに関する文書で、SSH接続の初期フェーズであるセキュリティ機能の確立とセッション鍵の交換を扱います。このプロトコルは、リモートコンピュータとの安全な通信チャネルを確立するために広く利用されています。関連するRFCには、RFC 4251（SSHプロトコルアーキテクチャ）、RFC 4252（SSH認証プロトコル）、RFC 4254（SSH接続プロトコル）があり、これらは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.
このドキュメントでは、SSHトランスポート層プロトコルについて説明します。これは通常、TCP / IP上で実行されます。このプロトコルは、多くの安全なネットワークサービスの基盤として使用できます。強力な暗号化、サーバー認証、および整合性保護を提供します。圧縮を提供することもあります。
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トランスポート層プロトコルの実装に必要な最小限のアルゴリズムセットについても説明します。
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
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往復です。
The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions.
このドキュメントセットの主要な元の貢献者は、Tatu Ylonen、Tero Kivinen、Timo J. Rinne、Sami Lehtinen（SSH Communications Security Corpのすべて）、およびMarkku-Juhani O. Saarinen（Jyvaskyla大学）です。ダレンモファットは、この一連のドキュメントの最初の編集者であり、非常に大きな貢献もしました。
Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it.
このドキュメントの開発には、長年にわたって多くの人々が貢献してくれました。認められるべき人には、マット・アンダーソン、ベン・ハリス、ビル・ソマーフェルト、ブレント・マクルーア、ニールス・モラー、ダミアン・ミラー、デレク・フォーカス、フランク・カザック、ヘイッキ・ノイシャイネン、ジェイコブ・シュリター、ジェフ・ヴァン・ダイク、ジェフリー・アルトマン、ジェフリー・ハッツェルマン、ジョン・ブライト、ジョセフガルブレイス、ケンホーンスタイン、マーカスフリードル、マーティンフォーセン、ニコラスウィリアムズ、ニールスプロボス、ペリーメッツガー、ピーターグトマン、サイモンジョセフソン、サイモンタサム、ウェイダイ、デニスビダー、マウス、デアマウス、河野忠義。ここに彼らの名前をリストすることは、彼らがこの文書を支持することを意味するのではなく、彼らがそれに貢献したことを意味します。
All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119].
SSHプロトコルに関連するすべてのドキュメントは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」を使用するものとします。要件を説明する「オプション」。これらのキーワードは、[RFC2119]で説明されているように解釈されます。
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434].
このドキュメントに表示されるキーワード「プライベート使用」、「階層割り当て」、「ファーストカムファーストサーブド」、「エキスパートレビュー」、「仕様が必要」、「IESG承認」、「IETFコンセンサス」、および「標準アクション」名前空間の割り当てを説明するために使用されるものは、[RFC2434]で説明されているように解釈されます。
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
プロトコルフィールドと、フィールドに入力できる値は、この一連のドキュメントで定義されています。プロトコルフィールドはメッセージ定義で定義されます。例として、SSH_MSG_CHANNEL_DATAは次のように定義されます。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
バイトSSH_MSG_CHANNEL_DATA uint32受信者チャネル文字列データ
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
これらのドキュメント全体で、フィールドが参照されている場合、フィールドは一重引用符で囲まれています。それらのフィールドを満たす値が参照される場合、それらは二重引用符で囲まれて表示されます。上記の例を使用すると、「data」の可能な値は「foo」と「bar」です。
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.
クライアントが接続を開始します。
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に割り当てられています。
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-softwareバージョン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 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）。
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 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ファイルに含まれています。
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.
互換モードでは、サーバーは、識別文字列を送信した後、クライアントから識別文字列を受信するまで、それ以上データを送信してはなりません（SHOULD NOT）。サーバーは、クライアントが古いプロトコルを使用しているかどうかを判断し、必要に応じて古いプロトコルに戻すことができます。互換モードでは、サーバーは識別文字列の前に追加のデータを送信してはなりません（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）。
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）。
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バイトになります（大体）。
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.
最大パケットサイズに関連する問題もあります。画面の更新の遅延を最小限に抑えるために、対話型セッションに過度に大きなパケットが必要になることはありません。最大パケットサイズは、チャネルごとに個別にネゴシエートされます。
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
packet_length The length of the packet in bytes, not including 'mac' or the 'packet_length' field itself.
packet_length「mac」または「packet_length」フィールド自体を含まない、バイト単位のパケットの長さ。
padding_length Length of 'random padding' (bytes).
padding_length「ランダムパディング」の長さ（バイト）。
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 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バイトが含まれます。最初は、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）。
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）。たとえば、実装が非常に多数の証明書を送信したい場合、相手がそれらを処理できることを識別文字列が示すと、より大きなパケットが送信される場合があります。ただし、実装では、サービス拒否攻撃やバッファオーバーフロー攻撃を回避するために、パケット長が妥当であることを確認する必要があります。
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」は、圧縮されたペイロードから計算されます。暗号化は圧縮後に行われます。
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
なし必須圧縮なしzlib OPTIONAL 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]で指定されているように、追加のメソッドを定義できます。
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）。例えば、初期化ベクトルはあるパケットの終わりから次のパケットの始めに渡されるべきです（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.
各方向の暗号は、互いに独立して実行する必要があります。ローカルポリシーで複数のアルゴリズムが許可されている場合、実装では、各方向のアルゴリズムを個別に選択できるようにする必要があります。ただし、実際には、同じアルゴリズムを両方向で使用することをお勧めします。
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 OPTIONAL CBCモードでのBlowfish twofish256-cbc OPTIONAL Twofish、CBCモードで、「twofish256-cbc」の256ビットキーtwofish-cbc OPTIONALエイリアス（これは保持されます）歴史上の理由から）twofish192-cbc OPTIONAL Twofish with 192-bit key twofish128-cbc OPTIONAL Twofish with a 128-bit key aes256-cbc OPTIONAL AES with CBC mode、with a 256-bit key aes192-cbc OPTIONAL AES with a 192-ビットキーaes128-cbc推奨AES、128ビットキーサーペント付き256-cbcオプションサーペント、CBCモード、256ビットキーサーペント付き192-cbcオプションサーペント、192ビットキーサーペント付き128-cbcオプションサーペント、128ビットキー付きarcfour OPTIONAL 128ビットキーを使用したARCFOURストリーム暗号idea-cbc CBCモードのOPTIONAL IDEA cast128-cbc CBCモードのOPTIONAL CAST-128なしOPTIONAL暗号化なし。推奨されません
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つのキーのトリプル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バイトのブロックを持つブロック暗号です。
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]で指定されているように、追加のメソッドを定義できます。
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)
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 OPTIONAL HMAC-MD5の最初の96ビット（ダイジェスト長= 12、キー長= 16）なしOPTIONAL 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ビットのみを使用します。
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]で指定されているように、追加のメソッドを定義できます。
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
diffie-hellman-group1-sha1が必要diffie-hellman-group14-sha1が必要
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に定義されたグループの間の関係を想定しないでください。
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 署名および/または暗号化アルゴリズム。鍵のタイプによっては、署名と暗号化の両方をサポートしていない場合があります。鍵の使用法は、ポリシーステートメント（証明書など）によっても制限される場合があります。この場合、異なるポリシーの選択肢に対して異なるキータイプを定義する必要があります。
o Encoding of signatures and/or encrypted data. This includes but is not limited to padding, byte order, and data formats.
o 署名および/または暗号化されたデータのエンコーディング。これには、パディング、バイト順、およびデータ形式が含まれますが、これらに限定されません。
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)
ssh-dss必須の署名未加工のDSS鍵ssh-rsa推奨の署名未加工のRSA鍵pgp-sign-rsaオプションの署名OpenPGP証明書（RSA鍵）pgp-sign-dss省略可能な署名OpenPGP証明書（DSS鍵）
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
文字列証明書または公開鍵形式識別子バイト[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.
文字列署名形式識別子（公開鍵/証明書形式で指定）バイト[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
文字列 "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を形成します。
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
文字列 "ssh-dss"文字列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
文字列 "ssh-rsa" mpint e mpint n
Here the 'e' and 'n' parameters form the signature key blob.
ここで、「e」および「n」パラメーターは署名鍵BLOBを形成します。
Signing and verifying using this key format is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.
この鍵形式を使用した署名と検証は、[RFC3447]のRSASSA-PKCS1-v1_5スキームに従って、SHA-1ハッシュを使用して実行されます。
The resulting signature is encoded as follows:
結果の署名は次のようにエンコードされます。
string "ssh-rsa" string rsa_signature_blob
文字列 "ssh-rsa"文字列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鍵であることを示しています。
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 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.
このドキュメントで定義されているキー交換方法は、明示的なサーバー認証を使用しています。ただし、暗黙のサーバー認証を使用する鍵交換方式は、このプロトコルで使用される場合があります。暗黙のサーバー認証による鍵交換の後、クライアントは、それ以上のデータを送信する前に、サービス要求メッセージへの応答を待機する必要があります。
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)
バイトSSH_MSG_KEXINITバイト[16] Cookie（ランダムバイト）名前リストkex_algorithms名前リストserver_host_key_algorithms名前リストencryption_algorithms_client_to_server名前リストencryption_algorithms_server_to_client name-list mac_algorithms_client_to_server name-server_client_to_list_client_to_client_list_client_to_client_list_client_to_client_list_client_to_client_list_client_to_client_to_client_to_server_client_to_client_to_server_client_to_client_to_server_client_to_server_client_to_server_client_to_server_client_to_server_client_to_server_client_to_client_to_list languages_server_to_client boolean first_kex_packet_follows uint32 0（将来の拡張のために予約済み）
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]の追加情報を参照）。サポートされている（許可されている）アルゴリズムはそれぞれ、優先順位の高いものから小さいものの順にリストしなければなりません（MUST）。
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「cookie」は、送信者が生成したランダムな値である必要があります。その目的は、どちらの側もキーとセッション識別子を完全に決定できないようにすることです。
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_algorithms鍵交換アルゴリズムは上記で定義されています。最初のアルゴリズムは、推奨（および推測）アルゴリズムでなければなりません。双方が同じ推測をする場合、そのアルゴリズムを使用しなければなりません。それ以外の場合は、次のアルゴリズムを使用して鍵交換方法を選択する必要があります：クライアントの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にも暗号化対応のアルゴリズムがあり、これもクライアントによってサポートされています。
+ 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 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.
server_host_key_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 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.
encryption_algorithms受け入れ可能な対称暗号化アルゴリズム（暗号とも呼ばれます）の優先順の名前リスト。各方向に選択された暗号化アルゴリズムは、サーバーの名前リストにもあるクライアントの名前リストの最初のアルゴリズムでなければなりません。そのようなアルゴリズムがない場合は、両側を切断する必要があります。
Note that "none" must be explicitly listed if it is to be acceptable. The defined algorithm names are listed in Section 6.3.
許容できる場合は、「なし」を明示的にリストする必要があることに注意してください。定義されたアルゴリズム名はセクション6.3にリストされています。
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_algorithms受け入れ可能な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.
許容できる場合は、「なし」を明示的にリストする必要があることに注意してください。 MACアルゴリズム名はセクション6.4にリストされています。
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.
compression_algorithms許容できる圧縮アルゴリズムの優先順の名前リスト。選択した圧縮アルゴリズムは、サーバーの名前リストにもあるクライアントの名前リストの最初のアルゴリズムでなければなりません。そのようなアルゴリズムがない場合は、両側を切断する必要があります。
Note that "none" must be explicitly listed if it is to be acceptable. The compression algorithm names are listed in Section 6.2.
許容できる場合は、「なし」を明示的にリストする必要があることに注意してください。圧縮アルゴリズム名はセクション6.2にリストされています。
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 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.
first_kex_packet_follows推測された鍵交換パケットが続くかどうかを示します。推測されたパケットが送信される場合、これは真でなければなりません。推測されたパケットが送信されない場合、これは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）。
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メッセージを受信する前に、処理中のメッセージをいくつでも処理できるように準備する必要があります。
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が生成したものと同じ）をキーに追加することにより、キーが拡張されます。このプロセスは、十分なキーマテリアルが利用可能になるまで繰り返されます。キーはこの値の最初から取得されます。言い換えると：
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 || ...
K1 = HASH（K || H || X || session_id）（Xは「A」など）K2 = HASH（K || H || K1）K3 = HASH（K || H || K1 || K2 ）...キー= 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の内部状態サイズよりも大きい場合、このプロセスはエントロピーを失います。
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
バイトSSH_MSG_NEWKEYS
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に送信します。
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
バイト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
バイトSSH_MSG_KEXDH_REPLY文字列サーバーの公開ホストの鍵と証明書（K_S）mpint f Hの文字列署名
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
文字列V_C、クライアントの識別文字列（CRおよびLFを除外）文字列V_S、サーバーの識別文字列（CRおよびLFを除外）文字列I_C、クライアントのSSH_MSG_KEXINIT文字列I_S、サーバーのSSH_MSG_KEXINIT文字列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でハッシュされます。
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」というフレーズを使用して名前が付けられていることに注意してください。
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グループ）として指定し、それもサポートする必要があります。
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メッセージで応答する必要があります。どちらの当事者も再交換を開始できますが、役割を変更してはなりません（つまり、サーバーはサーバーのままで、クライアントはクライアントのままです）。
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トランスポート層の上にあるプロトコルには影響しません。
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
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
バイトSSH_MSG_SERVICE_REQUEST文字列サービス名
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.
サービスが開始すると、キー交換中に生成されたセッション識別子にアクセスできます。
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
バイトSSH_MSG_SERVICE_ACCEPT文字列サービス名
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.
暗黙のサーバー認証による鍵交換の後、クライアントは、それ以上のデータを送信する前に、サービス要求メッセージへの応答を待たなければならないことに注意してください。
Either party may send any of the following messages at any time.
いずれの当事者も、次のメッセージをいつでも送信できます。
byte SSH_MSG_DISCONNECT uint32 reason code string description in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
ISO-10646 UTF-8エンコードのバイトSSH_MSG_DISCONNECT uint32理由コード文字列の説明[RFC3629]文字列言語タグ[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値であることに注意してください。
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]にあります。
byte SSH_MSG_IGNORE string data
バイトSSH_MSG_IGNORE文字列データ
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.
すべての実装は、いつでも（識別文字列を受け取った後）このメッセージを理解（および無視）する必要があります。それらを送信するための実装は必要ありません。このメッセージは、高度なトラフィック分析手法に対する追加の保護手段として使用できます。
byte SSH_MSG_DEBUG boolean always_display string message in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
ISO-10646 UTF-8エンコーディングのバイトSSH_MSG_DEBUG boolean always_display文字列メッセージ[RFC3629]文字列言語タグ[RFC3066]
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]で説明されている端末制御文字フィルタリングを使用して、端末制御文字を送信することによる攻撃を回避する必要があります。
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
拒否されたメッセージのバイトSSH_MSG_UNIMPLEMENTED uint32パケットシーケンス番号
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
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メソッドがこの範囲のメッセージ番号を再利用する場合があります。
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]で詳しく説明されています。
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]で提供されています。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、2006年1月。
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-CONNECT] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Connection Protocol」、RFC 4254、2006年1月。
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS] Lehtinen、S。およびC. Lonvick、編、「Secure Shell（SSH）Protocol Assigned Numbers」、RFC 4250、2006年1月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch、P. and J-L。ゲイリー、「ZLIB圧縮データ形式仕様バージョン3.3」、RFC 1950、1996年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144] Adams、C。、「CAST-128暗号化アルゴリズム」、RFC 2144、1997年5月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「OpenPGP Message Format」、RFC 2440、1998年11月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）のためのより多くのモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[FIPS-180-2] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002.
[FIPS-180-2]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、連邦情報処理標準出版物180-2、2002年8月。
[FIPS-186-2] US National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-2, January 2000.
[FIPS-186-2]米国国立標準技術研究所、「デジタル署名標準（DSS）」、連邦情報処理標準出版物186-2、2000年1月。
[FIPS-197] US National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001.
[FIPS-197]米国国立標準技術研究所、「Advanced Encryption Standard（AES）」、連邦情報処理標準出版物197、2001年11月。
[FIPS-46-3] US National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standards Publication 46-3, October 1999.
[FIPS-46-3]米国国立標準技術研究所、「Data Encryption Standard（DES）」、連邦情報処理標準出版物46-3、1999年10月。
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996.
[シュナイアー]シュナイアーB。、「Applied Cryptography Second Edition：protocol algorithm and source in code in C」、John Wiley and Sons、ニューヨーク、ニューヨーク、1996。
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition", March 1999.
[TWOFISH] Schneier、B。、「Twofish暗号化アルゴリズム：128ビットブロック暗号、第1版」、1999年3月。
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC0894] Hornig、C。、「イーサネットネットワーク上でのIPデータグラムの送信に関する標準」、STD 41、RFC 894、1984年4月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H。、「The OAKLEY鍵決定プロトコル」、RFC 2412、1998年11月。
[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.
[ssh-1.2.30] Ylonen、T。、「ssh-1.2.30 / RFC」、圧縮tarball内のファイルftp://ftp.funet.fi/pub/unix/security/login/ssh/ssh-1.2。 30.tar.gz、1995年11月。
Authors' Addresses
著者のアドレス
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinkiフィンランド
EMail: ylo@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
Chris Lonvick（編集者）Cisco Systems、Inc. 12515 Research Blvd.オースティン78759アメリカ
EMail: clonvick@cisco.com
Trademark Notice
商標に関する通知
"ssh" is a registered trademark in the United States and/or other countries.
「ssh」は、米国およびその他の国における登録商標です。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。