Network Working Group T. Ylonen
Request for Comments: 4253 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
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
安全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).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
Secure Shell（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
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.
该协议设计简单灵活，允许参数协商，并尽量减少往返次数。密钥交换方法、公钥算法、对称加密算法、消息认证算法和哈希算法都经过协商。预计在大多数环境中，完全密钥交换、服务器身份验证、服务请求和服务请求的接受通知只需要两次往返。最坏的情况是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大学）。达伦·莫法特（Darren Moffat）是这组文件的原始编辑，也做出了重大贡献。
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.
多年来，许多人为本文件的编写做出了贡献。应该承认的人包括马茨·安德森、本·哈里斯、比尔·索末菲、布伦特·麦克卢尔、尼尔斯·莫勒、达米恩·米勒、德里克·福库斯、弗兰克·库萨克、海基·努西亚宁、雅各布·施莱特、杰夫·范·戴克、杰弗里·奥特曼、杰弗里·哈泽尔曼、乔恩·布莱特、约瑟夫·加尔布雷斯、肯·霍恩斯坦、马克斯·弗里德、马丁·福森、尼古拉斯·威廉姆斯、，Niels Provos、Perry Metzger、Peter Gutmann、Simon Josefsson、Simon Tatham、Wei Dai、Denis Bider、der Mouse和Tadayoshi Kohno。在这里列出他们的名字并不意味着他们认可这份文件，而是意味着他们对这份文件作出了贡献。
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协议相关的文件应使用关键字“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”来描述要求。这些关键字将按照[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_数据定义如下。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
字节SSH\U MSG\U通道数据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".
在这些文档中，当引用字段时，它们将出现在单引号中。当引用填充这些字段的值时，它们将出现在双引号内。使用上述示例，“数据”的可能值为“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连接终止。
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原型软件版本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
由于这组文档中定义的协议是版本2.0，“protoversion”必须是“2.0”。“注释”字符串是可选的。如果包含“注释”字符串，则必须使用“空格”字符（上面表示为SP，ASCII 32）分隔“软件版本”和“注释”字符串。标识必须由单回车符（CR）和单行换行符（LF）字符（分别为ASCII 13和10）终止。希望维护
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.
由于本文件第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.
服务器可以在发送版本字符串之前发送其他行数据。每一行应通过回车和换行终止。此类行不得以“SSH-”开头，且应以ISO-10646 UTF-8[RFC3629]编码（未指定语言）。客户必须能够处理此类线路。这样的行可以被静默地忽略，或者可以显示给客户端用户。如果显示它们，则应使用[SSH-ARCH]中讨论的控件字符过滤。此功能的主要用途是允许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”字符串主要用于触发兼容性扩展并指示实现的功能。“comments”字符串应包含可能有助于解决用户问题的其他信息。因此，有效标识字符串的示例如下：
SSH-2.0-billsSSH_3.6.3q3<CR><LF>
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节所述。
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
如前所述，为本协议指定的“原型”为“2.0”。本协议的早期版本尚未正式记录，但众所周知，它们使用“1.x”的“原型”（例如，“1.5”或“1.3”）。在撰写本文时，许多SSH实现都在使用协议版本2.0，但众所周知，仍有一些设备使用以前的版本。在过渡期间，能够在一个良好的环境中工作是很重要的
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].
与使用旧版本协议的已安装SSH客户端和服务器兼容的方式。本节中的信息仅与支持与SSH版本1.x兼容的实现相关。对于那些感兴趣的人来说，1.x协议的唯一已知文档包含在自述文件中，自述文件与源代码[ssh-1.2.30]一起提供。
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.
服务器实现可能支持可配置的兼容性标志，以实现与旧版本的兼容性。启用此标志时，服务器应将其“protoversion”标识为“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.
在兼容模式下，服务器在从客户端接收到标识字符串之前，不应在发送其标识字符串后再发送任何数据。然后，服务器可以确定客户端是否使用旧协议，如果需要，可以恢复到旧协议。在兼容模式下，服务器不得在标识字符串之前发送其他数据。
When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string.
当不需要与旧客户端兼容时，服务器可以在标识字符串之后立即发送其初始密钥交换数据。
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.
由于新客户端可能会在其标识字符串之后（在接收服务器的标识字符串之前）立即发送附加数据，因此当客户端得知服务器是旧的时，旧协议可能已经损坏。发生这种情况时，客户端应关闭与服务器的连接，并使用旧协议重新连接。
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字节（取决于协商算法）。对于大数据包，增加的幅度可以忽略不计，但对于单字节数据包（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
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.
数据包长度数据包的长度（字节），不包括“mac”或“数据包长度”字段本身。
padding_length Length of 'random padding' (bytes).
padding_长度“随机填充”（字节）的长度。
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
随机填充任意长度填充，使得（数据包|长度|填充|长度|有效载荷| |随机填充）的总长度是密码块大小的倍数或8，以两者中的任意值为准
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.
更大的。必须至少有四个字节的填充。填充应该由随机字节组成。最大填充量为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个字节（或密码块大小，以较大者为准）后解密长度。
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字节或更少的数据包（包括“数据包长度”、“填充长度”、“有效负载”、“随机填充”和“mac”）。35000字节的最大值是一个任意选择的值，大于上面提到的未压缩长度。在可能需要的地方，实现应该支持更长的数据包。例如，如果实现想要发送非常多的证书，则如果标识字符串指示另一方能够处理它们，则可以发送较大的分组。但是，实现应检查数据包长度是否合理，以便实现避免拒绝服务和/或缓冲区溢出攻击。
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可选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.
[RFC1950]和[RFC1951]中描述了“zlib”压缩。压缩上下文在每次密钥交换后初始化，并从一个数据包传递到下一个数据包，仅在每个数据包的末尾执行部分刷新。部分刷新意味着当前压缩块结束，所有数据都将输出。如果当前块不是存储块，则在当前块之后添加一个或多个空块，以确保至少有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.
向一个方向发送的所有数据包中的加密数据应视为单个数据流。例如，初始化向量应该从一个数据包的末尾传递到下一个数据包的开头。所有密码应使用有效密钥长度为128位或以上的密钥。
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模式下需要三个键3des blowfish cbc可选blowfish在cbc模式下twofish256 cbc可选Twofish在cbc模式下使用256位键Twofish cbc可选别名表示“twofish256 cbc”（出于历史原因保留此选项）twofish192 cbc可选Twofish带有192位密钥twofish128 cbc可选Twofish带有128位密钥aes256 cbc可选AES处于cbc模式，带有256位密钥aes192 cbc可选AES带有192位密钥aes128 cbc推荐AES带有128位密钥Serpent 256 cbc可选Serpent处于cbc模式，带256位密钥的蛇192 cbc可选蛇带192位密钥的蛇128 cbc可选蛇带128位密钥的蛇arcfour可选arcfour带有128位密钥的流密码idea cbc可选idea cbc模式下cast128 cbc可选CAST-128 cbc模式下无可选无加密；不推荐
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”密码是三密钥三重DES（encrypt-decrypt-encrypt），其中密钥的前8个字节用于第一次加密，后8个字节用于解密，后8个字节用于最终加密。这需要24字节的密钥数据（其中实际使用了168位）。要实现CBC模式，必须使用外部链接（即，只有一个初始化向量）。这是一种具有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”或“twofish 256 cbc”密码是cbc模式下的twofish，具有所述的256位密钥[twofish]。这是一种具有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（高级加密标准）[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”密码，具有Serpent AES提交中所述的256位密钥。
The "serpent192-cbc" cipher is the same as above, but with a 192-bit key.
“蛇192 cbc”密码与上述密码相同，但具有192位密钥。
The "serpent128-cbc" cipher is the same as above, but with a 128-bit key.
“蛇128 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”密码是cbc模式下的CAST-128密码，具有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.
“none”算法指定不进行加密。请注意，此方法不提供保密保护，因此不推荐使用。如果选择此密码，出于安全原因，可能会禁用某些功能（例如密码验证）。
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（密钥、序列号、未加密的数据包）
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.
其中，未加密的_数据包是不带“mac”（长度字段、“有效载荷”和“随机填充”）的整个数据包，而sequence_number是表示为uint32的隐式数据包序列号。对于第一个数据包，序列号被初始化为零，并且在每个数据包之后递增（无论使用的是加密还是MAC）。即使以后重新协商密钥/算法，也不会重置。在每2^32个数据包之后，它会环绕到零。数据包序列号本身不包括在通过导线发送的数据包中。
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）无可选无MAC；不推荐
The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs use only the first n bits of the resulting value.
[RFC2104]中描述了“hmac-*”算法。“*-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:
定义了两种必需的密钥交换方法：
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；然而，对于另一个组，工作组采用了[RFC3526]指定的编号，使用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签名rsa可选签名OpenPGP证书（rsa密钥）pgp签名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].
根据数字签名标准[FIPS-186-2]，使用SHA-1散列[FIPS-180-2]，使用该密钥格式进行签名和验证。
The resulting signature is encoded as follows:
生成的签名编码如下：
string "ssh-dss" string dss_signature_blob
字符串“ssh dss”字符串dss\u签名\u 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\u signature\u 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\u签名\u 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的字符串（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符号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
密钥交换（kex）首先由各方发送支持算法的名称列表。每一方在每一类别中都有一个首选算法，并且假设在任何给定的时间，大多数实现都将使用相同的首选算法。各方都可以猜测
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.
另一方正在使用哪种算法，并且可以根据该算法发送初始密钥交换包（如果适用于首选方法）。
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\u MSG\u KEXINIT字节[16]cookie（随机字节）名称列表kex_算法名称列表服务器主机密钥算法名称列表加密算法客户端到服务器名称列表加密算法服务器到客户端名称列表mac_算法客户端到服务器名称列表mac_算法mac_算法mac_到服务器名称列表mac_算法服务器到客户端名称列表压缩算法客户端到服务器名称列表压缩算法服务器到客户端名称列表语言\u客户端\u到服务器名称列表语言\u服务器\u到客户端布尔值第一个\u kex\u数据包\u在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]中的其他信息）。每个支持的（允许的）算法必须按优先顺序列出，从大到小。
The first algorithm in each name-list MUST be the preferred (guessed) algorithm. Each name-list MUST contain at least one algorithm name.
每个名称列表中的第一个算法必须是首选（猜测）算法。每个名称列表必须至少包含一个算法名称。
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_算法密钥交换算法定义如上。第一个算法必须是首选（和猜测）算法。如果双方做出相同的猜测，则必须使用该算法。否则，必须使用以下算法来选择密钥交换方法：迭代客户端的kex算法，一次迭代一个。选择满足以下条件的第一个算法：
+ 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
+ 如果算法需要具有加密功能的主机密钥，则在服务器的服务器\u主机\u密钥\u算法上有一个具有加密功能的算法，客户端也支持该算法，以及
+ 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.
+ 如果算法需要支持签名的主机密钥，则在服务器的服务器\u主机\u密钥\u算法上有一个支持签名的算法，客户端也支持该算法。
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.
服务器主机密钥算法服务器主机密钥支持的算法的名称列表。服务器列出其具有主机密钥的算法；客户机列出了它愿意接受的算法。一个主机可能有多个主机密钥，可能使用不同的算法。
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.
加密算法按优先顺序列出可接受的对称加密算法（也称为密码）。选择的每个方向的加密算法必须是客户端名称列表上的第一个算法，也就是服务器名称列表上的第一个算法。如果没有这样的算法，双方必须断开连接。
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_算法按优先顺序列出可接受的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.
压缩算法按优先顺序列出可接受的压缩算法。选择的压缩算法必须是客户机名称列表上的第一个算法，也是服务器名称列表上的第一个算法。如果没有这样的算法，双方必须断开连接。
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]。双方可忽略此名单。如果没有语言首选项，则此名称列表应为空，如[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_follow表示猜测的密钥交换包是否跟随。如果一个猜测的数据包将被发送，这必须是真的。如果没有猜测到的数据包将被发送，这一定是错误的。
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数据包后，各方将知道他们的猜测是否正确。如果另一方的猜测是错误的，并且该字段为真，则必须默默地忽略下一个数据包，然后双方必须按照协商密钥交换方法确定的方式行事。如果猜测正确，则密钥交换必须继续使用猜测的数据包。
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节）之前，不得发送除以下消息以外的任何消息：
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_服务请求和SSH_MSG_服务接受）；
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。加密和身份验证密钥由此派生。来自第一个密钥交换的交换散列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.
每个密钥交换方法指定密钥交换中使用的哈希函数。密钥派生中必须使用相同的哈希算法。这里，我们称之为散列。
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客户端到服务器：散列（K | | H | | |“A”| |会话| id）（这里K编码为mpint，“A”编码为字节，会话| id编码为原始数据。“A”表示单个字符A，ASCII 65）。
o Initial IV server to client: HASH(K || H || "B" || session_id)
o 初始IV服务器到客户端：散列（K | | H | | |“B”| |会话| U id）
o Encryption key client to server: HASH(K || H || "C" || session_id)
o 客户端到服务器的加密密钥：散列（K | | H | | |“C”| |会话| id）
o Encryption key server to client: HASH(K || H || "D" || session_id)
o 加密密钥服务器到客户端：散列（K | | H | | |“D”| |会话| id）
o Integrity key client to server: HASH(K || H || "E" || session_id)
o 完整性密钥客户端到服务器：散列（K | | H | | |“E”| |会话| id）
o Integrity key server to client: HASH(K || H || "F" || session_id)
o 完整性密钥服务器到客户端：散列（K | | H | | |“F”| |会话| 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:
密钥数据必须从散列输出的开始处获取。从散列值的开头提取所需的字节数。如果所需的密钥长度大于散列的输出，则通过计算K和H的串联的散列以及迄今为止的整个密钥，并将结果字节（与散列生成的字节数一样多）附加到密钥来扩展密钥。重复此过程，直到有足够的关键材料可用；该键从该值的开始处获取。换言之：
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 | | | | | | | | | | | | | | | | | | 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中的熵大于散列的内部状态大小，则该过程将丢失熵。
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\u MSG\u 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向S发送e。
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。签名操作可能涉及第二个哈希操作。
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也可以在未经验证的情况下接受密钥；但是，这样做会使协议不安全，无法抵御主动攻击（但在许多环境中，出于实际原因，短期内可能是可取的）。然后计算K=f^x mod p，H=hash（V|C|V|S|I|C|I|u 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.
这是通过以下消息实现的。计算交换哈希的哈希算法由方法名定义，称为哈希。签名的公钥算法与SSH_MSG_KEXINIT消息协商。
First, the client sends the following:
首先，客户端发送以下信息：
byte SSH_MSG_KEXDH_INIT mpint e
字节SSH\u MSG\u KEXDH\u 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_回复字符串服务器公共主机密钥和证书（K_S）mpint f字符串签名H
The hash H is computed as the HASH hash of the concatenation of the following:
散列H被计算为以下各项的串联的散列：
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_的有效负载、服务器的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散列）。在这种情况下，首先使用散列对数据进行散列以计算H，然后作为签名操作的一部分，使用SHA-1对H进行散列。
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”方法指定diffie-hellman密钥交换，其中SHA-1作为散列，Oakley组2[RFC2409]（1024位MODP组）。必须支持此方法以实现互操作性，因为目前所有已知的实现都支持此方法。请注意，此方法使用短语“group1”命名，尽管它指定使用Oakley组2。
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”方法指定diffie-hellman密钥交换，其中SHA-1作为哈希，Oakley组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之前不会更改（如在初始密钥交换中）。重新交换的处理方式与初始密钥交换相同，但会话标识符将保持不变。允许在重新交换期间更改部分或全部算法。主机密钥也可以更改。交换后，将重新计算所有密钥和初始化向量。压缩和加密上下文被重置。
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.
建议在每传输一GB数据或每连接一小时后（以较早者为准）更改密钥。但是，由于重新交换是一种公钥操作，因此它需要相当大的处理能力，不应执行得太频繁。
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连接
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".
byte SSH_MSG_SERVICE_REQUEST string service name
字节SSH\u MSG\u服务\u请求字符串服务名称
If the server rejects the service request, it SHOULD send an appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
如果服务器拒绝服务请求，它应该发送相应的SSH\u MSG\u DISCONNECT消息，并且必须断开连接。
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\u MSG\u服务\u接受字符串服务名称
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]
字节SSH_MSG_DISCONNECT uint32原因码字符串说明，采用ISO-10646 UTF-8编码[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.
发件人在收到此邮件后不得发送或接收任何数据，收件人在收到此邮件后不得接受任何数据。断开连接消息“description”字符串以人类可读的形式给出了更具体的解释。断开连接消息“原因代码”以更具机器可读性的格式（适用于本地化）给出原因，其值如下表所示。请注意，为了便于阅读，此表中显示了十进制表示法，但这些值实际上是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
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.
如果显示“description”字符串，则应使用[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]所述，必须通过IETF协商一致方法，请求分配0x00000010至0xFDFFFF范围内的新断开连接消息“原因码”值（以及相关的“说明”文本）。0xFE000000到0xFFFFFF范围内的断开消息“原因代码”值保留供私人使用。如前所述，IANA的实际指令在[SSH-NUMBERS]中。
byte SSH_MSG_IGNORE string data
字节SSH\u MSG\u忽略字符串数据
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]
字节SSH\u MSG\u调试布尔值始终显示ISO-10646 UTF-8编码的字符串消息[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.
所有实现都必须理解此消息，但允许它们忽略它。此消息用于传输可能有助于调试的信息。如果“始终显示”为真，则应显示消息。否则，除非用户明确请求调试信息，否则不应显示。
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.
如果显示“message”字符串，则应使用[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_未实现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\u MSG\u断开连接1 SSH\u MSG\u忽略2 SSH\u MSG\u未实现3 SSH\u MSG\u调试4 SSH\u MSG\u服务请求5 SSH\u MSG\u服务\u接受6 SSH\u MSG\u KEXINIT 20 SSH\u MSG\u新密钥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，编辑，“安全外壳（SSH）协议架构”，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，Ed.，“安全外壳（SSH）认证协议”，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，编辑，“安全外壳（SSH）连接协议”，RFC 42542006年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，Ed.，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch，P.和J-L.Gailly，“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压缩数据格式规范1.3版”，RFC1951，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：用于消息认证的键控哈希”，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加密算法”，RFC2144，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，“在RFCs中编写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消息格式”，RFC 24401998年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，“公钥密码标准（PKCS）#1:RSA密码规范版本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]美国国家标准与技术研究所，“安全哈希标准（SHS）”，联邦信息处理标准出版物180-22002年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]美国国家标准与技术研究所，“高级加密标准（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]美国国家标准与技术研究所，“数据加密标准（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.
[SCHNEIER]SCHNEIER，B.，“应用密码学第二版：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]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，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/ 登录/ssh/ssh-1.2.30.tar.gz，1995年11月。
Authors' Addresses
作者地址
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
芬兰赫尔辛基塔图伊洛宁SSH通信安全公司Valimotie 17 00380
EMail: ylo@ssh.com
EMail: ylo@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
Chris Lonvick（编辑）思科系统公司，研究大道12515号。美国奥斯汀78759
EMail: clonvick@cisco.com
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).
版权所有（C）互联网协会（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。