Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 8308 Bitvise Limited
Updates: 4251, 4252, 4253, 4254 March 2018
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 8308 Bitvise Limited
Updates: 4251, 4252, 4253, 4254 March 2018
Category: Standards Track
ISSN: 2070-1721
Extension Negotiation in the Secure Shell (SSH) Protocol
安全Shell（SSH）协议中的扩展协商
Abstract
摘要
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.
本备忘录通过定义一种机制来更新RFCs 4251、4252、4253和4254，该机制用于安全外壳（SSH）客户端和服务器在SSH密钥交换后秘密交换有关支持的协议扩展的信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8308.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8308.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview and Rationale ..........................................3
1.1. Requirements Terminology ...................................3
1.2. Wire Encoding Terminology ..................................3
2. Extension Negotiation Mechanism .................................3
2.1. Signaling of Extension Negotiation in SSH_MSG_KEXINIT ......3
2.2. Enabling Criteria ..........................................4
2.3. SSH_MSG_EXT_INFO Message ...................................4
2.4. Message Order ..............................................5
2.5. Interpretation of Extension Names and Values ...............6
3. Initially Defined Extensions ....................................6
3.1. "server-sig-algs" ..........................................6
3.2. "delay-compression" ........................................7
3.2.1. Awkwardly Timed Key Re-Exchange .....................9
3.2.2. Subsequent Re-Exchange ..............................9
3.2.3. Compatibility Note: OpenSSH up to Version 7.5 .......9
3.3. "no-flow-control" .........................................10
3.3.1. Prior "No Flow Control" Practice ...................10
3.4. "elevation" ...............................................11
4. IANA Considerations ............................................12
4.1. Additions to Existing Registries ..........................12
4.2. New Registry: Extension Names .............................12
4.2.1. Future Assignments to Extension Names Registry .....12
5. Security Considerations ........................................12
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
Acknowledgments ...................................................14
Author's Address ..................................................14
1. Overview and Rationale ..........................................3
1.1. Requirements Terminology ...................................3
1.2. Wire Encoding Terminology ..................................3
2. Extension Negotiation Mechanism .................................3
2.1. Signaling of Extension Negotiation in SSH_MSG_KEXINIT ......3
2.2. Enabling Criteria ..........................................4
2.3. SSH_MSG_EXT_INFO Message ...................................4
2.4. Message Order ..............................................5
2.5. Interpretation of Extension Names and Values ...............6
3. Initially Defined Extensions ....................................6
3.1. "server-sig-algs" ..........................................6
3.2. "delay-compression" ........................................7
3.2.1. Awkwardly Timed Key Re-Exchange .....................9
3.2.2. Subsequent Re-Exchange ..............................9
3.2.3. Compatibility Note: OpenSSH up to Version 7.5 .......9
3.3. "no-flow-control" .........................................10
3.3.1. Prior "No Flow Control" Practice ...................10
3.4. "elevation" ...............................................11
4. IANA Considerations ............................................12
4.1. Additions to Existing Registries ..........................12
4.2. New Registry: Extension Names .............................12
4.2.1. Future Assignments to Extension Names Registry .....12
5. Security Considerations ........................................12
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
Acknowledgments ...................................................14
Author's Address ..................................................14
Secure Shell (SSH) is a common protocol for secure communication on the Internet. The original design of the SSH transport layer [RFC4253] lacks proper extension negotiation. Meanwhile, diverse implementations take steps to ensure that known message types contain no unrecognized information. This makes it difficult for implementations to signal capabilities and negotiate extensions without risking disconnection. This obstacle has been recognized in the process of updating SSH to support RSA signatures using SHA-256 and SHA-512 [RFC8332]. To avoid trial and error as well as authentication penalties, a client must be able to discover public key algorithms a server accepts. This extension mechanism permits this discovery.
Secure Shell（SSH）是Internet上用于安全通信的通用协议。SSH传输层[RFC4253]的原始设计缺乏适当的扩展协商。同时，不同的实现采取步骤确保已知的消息类型不包含无法识别的信息。这使得实现很难在不冒断开连接风险的情况下发出功能信号并协商扩展。在使用SHA-256和SHA-512[RFC8332]更新SSH以支持RSA签名的过程中，已经发现了这个障碍。为了避免反复试验和验证惩罚，客户机必须能够发现服务器接受的公钥算法。这种扩展机制允许这种发现。
This memo updates RFCs 4251, 4252, 4253, and 4254.
本备忘录更新了RFCs 4251、4252、4253和4254。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The wire encoding types in this document -- "byte", "uint32", "string", "boolean", "name-list" -- have meanings as described in [RFC4251].
本文档中的导线编码类型--“字节”、“uint32”、“字符串”、“布尔值”、“名称列表”--具有[RFC4251]中所述的含义。
Applications implementing this mechanism MUST add one of the following indicator names to the field kex_algorithms in the SSH_MSG_KEXINIT message sent by the application in the first key exchange:
实现此机制的应用程序必须在应用程序在第一次密钥交换中发送的SSH_MSG_KEXINIT消息中的字段kex_算法中添加以下指示符名称之一：
o When acting as server: "ext-info-s"
o 当充当服务器时：“ext-info-s”
o When acting as client: "ext-info-c"
o 作为客户时：“ext-info-c”
The indicator name is added without quotes and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions.
添加的指示器名称不带引号，可添加在名称列表中的任何位置，但须按照名称列表约定与其他名称适当分开。
The names are added to the kex_algorithms field because this is one of two name-list fields in SSH_MSG_KEXINIT that do not have a separate copy for each data direction.
这些名称被添加到kex_algorithms字段，因为这是SSH_MSG_KEXINIT中两个名称列表字段之一，每个数据方向没有单独的副本。
The indicator names inserted by the client and server are different to ensure these names will not produce a match and therefore not affect the algorithm chosen in key exchange algorithm negotiation.
客户端和服务器插入的指示符名称不同，以确保这些名称不会产生匹配，因此不会影响密钥交换算法协商中选择的算法。
The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism.
包含文本指示符名称的目的是为实现者发现这种机制提供线索。
If a client or server offers "ext-info-c" or "ext-info-s" respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer.
如果客户机或服务器分别提供“ext-info-c”或“ext-info-s”，则必须准备好接受来自对等方的SSH_MSG_ext_info消息。
A server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. A client only needs to send "ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server.
如果服务器打算处理来自客户端的SSH_MSG_ext_信息，则只需要发送“ext-info-s”。如果客户机计划从服务器处理SSH_MSG_ext_信息，则只需要发送“ext-info-c”。
If a server receives an "ext-info-c", or a client receives an "ext-info-s", it MAY send an SSH_MSG_EXT_INFO message but is not required to do so.
如果服务器接收到“ext-info-c”，或者客户端接收到“ext-info-s”，它可能会发送SSH_MSG_ext_info消息，但不需要这样做。
Neither party needs to wait for the other's SSH_MSG_KEXINIT in order to decide whether to send the appropriate indicator in its own SSH_MSG_KEXINIT.
任何一方都不需要等待对方的SSH_MSG_KEXINIT来决定是否在自己的SSH_MSG_KEXINIT中发送适当的指示符。
Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counterparty sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect.
实现不得为其角色发送错误的指示符名称。如果交易对手发送了错误的指标，实施可能会中断。如果“ext-info-c”或“ext-info-s”最终作为密钥交换方法进行协商，双方必须断开连接。
A party that received the "ext-info-c" or "ext-info-s" indicator MAY send the following message:
收到“ext-info-c”或“ext-info-s”指示器的一方可发送以下信息：
byte SSH_MSG_EXT_INFO (value 7) uint32 nr-extensions repeat the following 2 fields "nr-extensions" times: string extension-name string extension-value (binary)
字节SSH_MSG_EXT_INFO（值7）uint32 nr扩展重复以下两个字段“nr扩展”次数：字符串扩展名字符串扩展值（二进制）
Implementers should pay careful attention to Section 2.5, in particular to the requirement to tolerate any sequence of bytes (including null bytes at any position) in an unknown extension's extension-value.
实现者应该仔细注意第2.5节，特别是在未知扩展的扩展值中容忍任何字节序列（包括任何位置的空字节）的要求。
If a client sends SSH_MSG_EXT_INFO, it MUST send it as the next packet following the client's first SSH_MSG_NEWKEYS message to the server.
如果客户端发送SSH\u MSG\u EXT\u INFO，它必须将其作为客户端第一条SSH\u MSG\u NEWKEYS消息后的下一个数据包发送到服务器。
If a server sends SSH_MSG_EXT_INFO, it MAY send it at zero, one, or both of the following opportunities:
如果服务器发送SSH\u MSG\u EXT\u INFO，则可能会在以下情况下零次、一次或两次发送：
o As the next packet following the server's first SSH_MSG_NEWKEYS.
o 作为服务器第一个SSH\u MSG\u NEWKEYS之后的下一个数据包。
Where clients need information in the server's SSH_MSG_EXT_INFO to authenticate, it is helpful if the server sends its SSH_MSG_EXT_INFO not only as the next packet after SSH_MSG_NEWKEYS, but without delay.
当客户端需要服务器的SSH_MSG_EXT_信息中的信息进行身份验证时，如果服务器不仅将其SSH_MSG_EXT_信息作为SSH_MSG_NEWKEYS之后的下一个数据包发送，而且毫不延迟地发送，这会很有帮助。
Clients cannot rely on this because the server is not required to send the message at this time; if sent, it may be delayed by the network. However, if a timely SSH_MSG_EXT_INFO is received, a client can pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when it needs extension information.
客户机不能依赖于此，因为此时不需要服务器发送消息；如果发送，可能会被网络延迟。但是，如果及时收到SSH\u MSG\u EXT\u信息，客户机可以在其SSH\u MSG\u服务请求之后通过管道发送身份验证请求，即使它需要扩展信息。
o Immediately preceding the server's SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].
o 服务器SSH_MSG_USERAUTH_成功之前，如[RFC4252]中所定义。
The server MAY send SSH_MSG_EXT_INFO at this second opportunity, whether or not it sent it at the first. A client that sent "ext-info-c" MUST accept a server's SSH_MSG_EXT_INFO at both opportunities but MUST NOT require it.
服务器可能会在第二次机会发送SSH_MSG_EXT_信息，无论是否在第一次机会发送。发送“ext-info-c”的客户端必须同时接受服务器的SSH\u MSG\u ext\u信息，但不能要求它。
This allows a server to reveal support for additional extensions that it was unwilling to reveal to an unauthenticated client. If a server sends a second SSH_MSG_EXT_INFO, this replaces any initial one, and both the client and the server re-evaluate extensions in effect. The server's second SSH_MSG_EXT_INFO is matched against the client's original.
这允许服务器向未经身份验证的客户机透露它不愿意透露的对其他扩展的支持。如果服务器发送第二个SSH\u MSG\u EXT\u信息，则会替换任何初始信息，并且客户端和服务器都会重新评估有效的扩展。服务器的第二个SSH\u MSG\u EXT\u信息与客户端的原始信息匹配。
The timing of the second opportunity is chosen for the following reasons. If the message was sent earlier, it would not allow the server to withhold information until the client has authenticated. If it was sent later, a client that needs information from the second SSH_MSG_EXT_INFO immediately after it authenticates would have no way to reliably know whether to expect the message.
选择第二次机会的时机是出于以下原因。如果消息是在更早的时候发送的，则在客户端进行身份验证之前，服务器将不允许保留信息。如果稍后发送，则在验证后立即需要来自第二个SSH_MSG_EXT_INFO的信息的客户端将无法可靠地知道是否需要该消息。
Each extension is identified by its extension-name and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names.
每个扩展都由其扩展名标识，并定义扩展生效的条件。应用程序必须忽略无法识别的扩展名。
When it is specified, an extension MAY dictate that, in order to take effect, both parties must include it in their SSH_MSG_EXT_INFO or that it is sufficient for only one party to include it. However, other rules MAY be specified. The relative order in which extensions appear in an SSH_MSG_EXT_INFO message MUST be ignored.
当指定时，扩展可以规定，为了生效，双方必须将其包含在其SSH_MSG_EXT_信息中，或者仅一方包含即可。但是，可以指定其他规则。必须忽略SSH_MSG_EXT_INFO消息中扩展出现的相对顺序。
Extension-value fields are interpreted as defined by their respective extension. This field MAY be empty if permitted by the extension. Applications that do not implement or recognize an extension MUST ignore its extension-value, regardless of its size or content. Applications MUST tolerate any sequence of bytes -- including null bytes at any position -- in an unknown extension's extension-value.
扩展值字段按其各自的扩展定义进行解释。如果扩展允许，此字段可能为空。不实现或不识别扩展的应用程序必须忽略其扩展值，无论其大小或内容如何。应用程序必须容忍未知扩展的扩展值中的任何字节序列，包括任何位置的空字节。
The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with [RFC4253]. Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept.
SSH_MSG_EXT_INFO消息的累积大小仅受实现可能根据[RFC4253]应用的最大数据包长度的限制。实现必须接受格式良好的SSH\u MSG\u EXT\u INFO消息，最大长度为它们接受的数据包长度。
This extension is sent with the following extension name and value:
此扩展名随以下扩展名和值一起发送：
string "server-sig-algs" name-list public-key-algorithms-accepted
接受字符串“服务器sig algs”名称列表公钥算法
The name-list type is a strict subset of the string type and is thus permissible as an extension-value. See [RFC4251] for more information.
名称列表类型是字符串类型的严格子集，因此允许作为扩展值。有关更多信息，请参阅[RFC4251]。
This extension is sent by the server and contains a list of public key algorithms that the server is able to process as part of a "publickey" authentication request. If a client sends this extension, the server MAY ignore it and MAY disconnect.
此扩展由服务器发送，并包含服务器能够作为“公钥”身份验证请求的一部分处理的公钥算法列表。如果客户端发送此扩展，服务器可能会忽略它并断开连接。
In this extension, a server MUST enumerate all public key algorithms it might accept during user authentication. However, early server implementations that do not enumerate all accepted algorithms do
在此扩展中，服务器必须枚举在用户身份验证期间可能接受的所有公钥算法。但是，早期的服务器实现不会枚举所有已接受的算法
exist. For this reason, a client MAY send a user authentication request using a public key algorithm not included in "server-sig-algs".
存在因此，客户端可以使用“服务器sig algs”中未包含的公钥算法发送用户身份验证请求。
A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate public key algorithm, rather than resorting to trial and error.
希望继续进行公钥身份验证的客户端可能会等待服务器的SSH_MSG_EXT_INFO，以便它可以使用适当的公钥算法发送“公钥”身份验证请求，而不是诉诸于反复试验。
Servers that implement public key authentication SHOULD implement this extension.
实现公钥身份验证的服务器应实现此扩展。
If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support, and MAY proceed with authentication requests using trial and error. Note that implementations are known to exist that apply authentication penalties if the client attempts to use an unexpected public key algorithm.
如果服务器不发送此扩展，则客户端不得对服务器的公钥算法支持做出任何假设，并且可以使用试错法处理身份验证请求。请注意，已知存在这样的实现：如果客户端尝试使用意外的公钥算法，则会应用身份验证惩罚。
Authentication penalties are applied by servers to deter brute-force password guessing, username enumeration, and other types of behavior deemed suspicious by server administrators or implementers. Penalties may include automatic IP address throttling or blocking, and they may trigger email alerts or auditing.
服务器应用身份验证惩罚来阻止暴力破解密码猜测、用户名枚举以及服务器管理员或实现者认为可疑的其他类型的行为。惩罚可能包括自动限制或阻止IP地址，并可能触发电子邮件警报或审核。
This extension MAY be sent by both parties as follows:
本延期可由双方按如下方式发送：
string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client
字符串“延迟压缩”字符串：名称列表压缩算法客户端到服务器名称列表压缩算法服务器到客户端
The extension-value is a string that encodes two name-lists. The name-lists themselves have the encoding of strings. For example, to indicate a preference for algorithms "foo,bar" in the client-to-server direction and "bar,baz" in the server-to-client direction, a sender encodes the extension-value as follows (including its length):
扩展名值是对两个名称列表进行编码的字符串。名称列表本身具有字符串编码。例如，为了指示客户端到服务器方向上算法“foo，bar”和服务器到客户端方向上算法“bar，baz”的首选项，发送方将扩展值编码如下（包括其长度）：
00000016 00000007 666f6f2c626172 00000007 6261722c62617a
000000 16 0000000 7 666f6f2c626172 0000000 7 6261722c62617a
This same encoding could be sent by either party -- client or server.
任何一方都可以发送相同的编码——客户机或服务器。
This extension allows the server and client to renegotiate compression algorithm support without having to conduct a key re-exchange, which puts new algorithms into effect immediately upon successful authentication.
此扩展允许服务器和客户端重新协商压缩算法支持，而无需执行密钥重新交换，从而在成功验证后立即使新算法生效。
This extension takes effect only if both parties send it. Name-lists MAY include any compression algorithm that could have been negotiated in SSH_MSG_KEXINIT, except algorithms that define their own delayed compression semantics. This means "zlib,none" is a valid algorithm list in this context, but "zlib@openssh.com" is not.
此扩展仅在双方都发送时生效。名称列表可能包括可能在SSH_MSG_KEXINIT中协商的任何压缩算法，但定义自己的延迟压缩语义的算法除外。这意味着“zlib，none”在此上下文中是一个有效的算法列表，但是zlib@openssh.com”“不是。
If both parties send this extension, but the name-lists do not contain a common algorithm in either direction, the parties MUST disconnect in the same way as if negotiation failed as part of SSH_MSG_KEXINIT.
如果双方都发送此扩展，但名称列表在两个方向上都不包含通用算法，则双方必须以与SSH_MSG_KEXINIT协商失败相同的方式断开连接。
If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message:
如果此扩展生效，将为触发消息之后的下一条SSH消息激活重新协商的压缩算法：
o Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS.
o 由服务器发送的触发消息是SSH\u MSG\u USERAUTH\u SUCCESS。
o Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.
o 由客户端发送的触发消息是SSH_MSG_NEWCOMPRESS。
If this extension takes effect, the client MUST send the following message within a reasonable number of outgoing SSH messages after receiving SSH_MSG_USERAUTH_SUCCESS, but not necessarily as the first such outgoing message:
如果此扩展生效，客户端在收到SSH_MSG_USERAUTH_SUCCESS后，必须在合理数量的传出SSH消息内发送以下消息，但不一定作为第一条此类传出消息：
byte SSH_MSG_NEWCOMPRESS (value 8)
字节SSH\u MSG\u（值8）
The purpose of SSH_MSG_NEWCOMPRESS is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's SSH_MSG_USERAUTH_SUCCESS. For example, clients may send keep-alive messages during logon processing.
SSH_MSG_NEWCOMPRESS的目的是避免出现争用情况，即服务器无法可靠地知道客户端发送的消息是在收到服务器的SSH_MSG_USERAUTH_成功之前还是之后发送的。例如，客户端可能在登录处理期间发送保持活动状态的消息。
As is the case for all extensions unless otherwise noted, the server MAY delay including this extension until its secondary SSH_MSG_EXT_INFO, sent before SSH_MSG_USERAUTH_SUCCESS. This allows the server to avoid advertising compression until the client has authenticated.
与所有扩展的情况一样，除非另有说明，否则服务器可能会延迟包含此扩展，直到在SSH\u MSG\u USERAUTH\u成功之前发送其辅助SSH\u MSG\u EXT\u信息。这允许服务器在客户端进行身份验证之前避免广告压缩。
If the parties renegotiate compression using this extension in a session where compression is already enabled and the renegotiated algorithm is the same in one or both directions, then the internal compression state MUST be reset for each direction at the time the renegotiated algorithm takes effect.
如果双方在已启用压缩且重新协商的算法在一个或两个方向上相同的会话中使用此扩展重新协商压缩，则在重新协商的算法生效时，必须为每个方向重置内部压缩状态。
A party that has signaled, or intends to signal, support for this extension in an SSH session MUST NOT initiate key re-exchange in that session until either of the following occurs:
在SSH会话中发出或打算发出支持此扩展的信号的一方不得在该会话中启动密钥重新交换，除非发生以下任一情况：
o This extension was negotiated, and the party that's about to start key re-exchange already sent its trigger message for compression.
o 此扩展已协商，即将开始密钥重新交换的一方已发送其用于压缩的触发消息。
o The party has sent (if server) or received (if client) the message SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated.
o 参与方已发送（如果是服务器）或接收（如果是客户端）消息SSH\u MSG\u USERAUTH\u SUCCESS，并且未协商此扩展。
If a party violates this rule, the other party MAY disconnect.
如果一方违反此规则，另一方可以断开连接。
In general, parties SHOULD NOT start key re-exchange before successful user authentication but MAY tolerate it if not using this extension.
通常，各方不应在成功进行用户身份验证之前开始密钥重新交换，但如果不使用此扩展，则可以容忍密钥重新交换。
In subsequent key re-exchanges that unambiguously begin after the compression trigger messages, the compression algorithms negotiated in re-exchange override the algorithms negotiated with this extension.
在压缩触发消息之后明确开始的后续密钥重新交换中，在重新交换中协商的压缩算法将覆盖与此扩展协商的算法。
This extension uses a binary extension-value encoding. OpenSSH clients up to and including version 7.5 advertise support to receive SSH_MSG_EXT_INFO but disconnect on receipt of an extension-value containing null bytes. This is an error fixed in OpenSSH version 7.6.
此扩展使用二进制扩展值编码。版本7.5之前（含版本7.5）的OpenSSH客户端将公布支持以接收SSH_MSG_EXT_信息，但在收到包含空字节的扩展值时断开连接。这是OpenSSH版本7.6中修复的错误。
Implementations that wish to interoperate with OpenSSH 7.5 and earlier are advised to check the remote party's SSH version string and omit this extension if an affected version is detected. Affected versions do not implement this extension, so there is no harm in omitting it. The extension SHOULD NOT be omitted if the detected OpenSSH version is 7.6 or higher. This would make it harder for the OpenSSH project to implement this extension in a higher version.
建议希望与OpenSSH 7.5及更早版本互操作的实现检查远程方的SSH版本字符串，如果检测到受影响的版本，则忽略此扩展。受影响的版本不实现此扩展，因此省略它没有什么害处。如果检测到的OpenSSH版本为7.6或更高版本，则不应忽略扩展。这将使OpenSSH项目更难在更高版本中实现此扩展。
This extension is sent with the following extension name and value:
此扩展名随以下扩展名和值一起发送：
string "no-flow-control" string choice of: "p" for preferred | "s" for supported
字符串“无流量控制”字符串选择：“p”表示首选，选择“s”表示支持
A party SHOULD send "s" if it supports "no-flow-control" but does not prefer to enable it. A party SHOULD send "p" if it prefers to enable the extension if the other party supports it. Parties MAY disconnect if they receive a different extension value.
如果一方支持“无流量控制”，但不愿意启用，则应发送“s”。如果一方希望在另一方支持的情况下启用扩展，则应发送“p”。如果各方收到不同的扩展值，则可能会断开连接。
For this extension to take effect, the following must occur:
要使此扩展生效，必须执行以下操作：
o This extension MUST be sent by both parties.
o 此扩展必须由双方发送。
o At least one party MUST have sent the value "p" (preferred).
o 必须至少有一方发送了值“p”（首选）。
If this extension takes effect, the "initial window size" fields in SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in [RFC4254], become meaningless. The values of these fields MUST be ignored, and a channel behaves as if all window sizes are infinite. Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such messages MUST be ignored.
如果此扩展生效，[RFC4254]中定义的SSH_MSG_CHANNEL_OPEN和SSH_MSG_CHANNEL_OPEN_CONFIRMATION中的“初始窗口大小”字段将变得毫无意义。必须忽略这些字段的值，通道的行为就像所有窗口大小都是无限的一样。双方都不需要发送任何SSH\u MSG\u CHANNEL\u WINDOW\u ADJUST消息，如果收到这些消息，则必须忽略这些消息。
This extension is intended for, but not limited to, use by file transfer applications that are only going to use one channel and for which the flow control provided by SSH is an impediment, rather than a feature.
此扩展用于但不限于仅使用一个通道的文件传输应用程序，而SSH提供的流控制是该应用程序的障碍，而不是功能。
Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel.
当此扩展生效时，实现必须拒绝同时打开多个通道。然而，服务器实现应该支持客户端打开多个非同时通道。
Before this extension, some applications would simply not implement SSH flow control, sending an initial channel window size of 2^32 - 1. Applications SHOULD NOT do this for the following reasons:
在此扩展之前，一些应用程序根本不会实现SSH流控制，发送初始通道窗口大小为2^32-1。由于以下原因，应用程序不应这样做：
o It is plausible to transfer more than 2^32 bytes over a channel. Such a channel will hang if the other party implements SSH flow control according to [RFC4254].
o 在一个通道上传输超过2^32字节是合理的。如果另一方根据[RFC4254]实现SSH流控制，则该通道将挂起。
o Implementations that cannot handle large channel window sizes exist, and they can exhibit non-graceful behaviors, including disconnect.
o 存在无法处理大通道窗口大小的实现，并且它们可能表现出不优雅的行为，包括断开连接。
The terms "elevation" and "elevated" refer to an operating system mechanism where an administrator's logon session is associated with two security contexts: one limited and one with administrative rights. To "elevate" such a session is to activate the security context with full administrative rights. For more information about this mechanism on Windows, see [WINADMIN] and [WINTOKEN].
术语“提升”和“提升”指的是一种操作系统机制，其中管理员的登录会话与两个安全上下文相关联：一个是受限的，另一个是具有管理权限的。“提升”这样一个会话就是激活具有完全管理权限的安全上下文。有关Windows上此机制的更多信息，请参阅[WINADMIN]和[WINTOKEN]。
This extension MAY be sent by the client as follows:
此扩展可由客户端按如下方式发送：
string "elevation"
string choice of: "y" | "n" | "d"
string "elevation"
string choice of: "y" | "n" | "d"
A client sends "y" to indicate its preference that the session should be elevated; "n" to not be elevated; and "d" for the server to use its default behavior. The server MAY disconnect if it receives a different extension value. If a client does not send the "elevation" extension, the server SHOULD act as if "d" was sent.
客户端发送“y”以指示其会话应提升的偏好；“n”不得升高；和“d”表示服务器使用其默认行为。如果服务器接收到不同的扩展值，则可能会断开连接。如果客户机不发送“提升”扩展，则服务器应该像发送了“d”一样工作。
If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request:
如果客户端包含此扩展，则在身份验证后，支持此扩展的服务器应通过发送以下全局请求向客户端指示是否完成了提升：
byte SSH_MSG_GLOBAL_REQUEST string "elevation" boolean want reply = false boolean elevation performed
字节SSH\u MSG\u GLOBAL\u请求字符串“elevation”boolean want reply=执行了错误的布尔提升
Clients that implement this extension help reduce attack surface for Windows servers that handle administrative logins. Where clients do not support this extension, servers must elevate sessions to allow full access by administrative users always. Where clients support this extension, sessions can be created without elevation unless requested.
实现此扩展的客户端有助于减少处理管理登录的Windows服务器的攻击面。当客户端不支持此扩展时，服务器必须提升会话以始终允许管理用户完全访问。在客户端支持此扩展的情况下，除非有要求，否则可以创建不带提升的会话。
IANA has added the following entries to the "Message Numbers" registry [IANA-M] under the "Secure Shell (SSH) Protocol Parameters" registry [RFC4250]:
IANA已将以下条目添加到“安全外壳（SSH）协议参数”注册表[RFC4250]下的“消息编号”注册表[IANA-M]：
Value Message ID Reference
-----------------------------------------
7 SSH_MSG_EXT_INFO RFC 8308
8 SSH_MSG_NEWCOMPRESS RFC 8308
Value Message ID Reference
-----------------------------------------
7 SSH_MSG_EXT_INFO RFC 8308
8 SSH_MSG_NEWCOMPRESS RFC 8308
IANA has also added the following entries to the "Key Exchange Method Names" registry [IANA-KE]:
IANA还向“密钥交换方法名称”注册表[IANA-KE]添加了以下条目：
Method Name Reference Note
------------------------------------------
ext-info-s RFC 8308 Section 2
ext-info-c RFC 8308 Section 2
Method Name Reference Note
------------------------------------------
ext-info-s RFC 8308 Section 2
ext-info-c RFC 8308 Section 2
Also under the "Secure Shell (SSH) Protocol Parameters" registry, IANA has created a new "Extension Names" registry, with the following initial content:
IANA还在“Secure Shell（SSH）协议参数”注册表下创建了一个新的“扩展名”注册表，初始内容如下：
Extension Name Reference Note
------------------------------------------------
server-sig-algs RFC 8308 Section 3.1
delay-compression RFC 8308 Section 3.2
no-flow-control RFC 8308 Section 3.3
elevation RFC 8308 Section 3.4
Extension Name Reference Note
------------------------------------------------
server-sig-algs RFC 8308 Section 3.1
delay-compression RFC 8308 Section 3.2
no-flow-control RFC 8308 Section 3.3
elevation RFC 8308 Section 3.4
Names in the "Extension Names" registry MUST follow the conventions for names defined in [RFC4250], Section 4.6.1.
“扩展名”注册表中的名称必须遵循[RFC4250]第4.6.1节中定义的名称惯例。
Requests for assignments of new non-local names in the "Extension Names" registry (i.e., names not including the '@' character) MUST be done using the IETF Review policy, as described in [RFC8126].
如[RFC8126]所述，在“扩展名”注册表中分配新的非本地名（即不包含“@”字符的名称）的请求必须使用IETF审查策略完成。
Security considerations are discussed throughout this document. This document updates the SSH protocol as defined in [RFC4251] and related documents. The security considerations of [RFC4251] apply.
本文档中讨论了安全注意事项。本文档更新了[RFC4251]和相关文档中定义的SSH协议。[RFC4251]的安全注意事项适用。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.
[RFC4250]Lehtinen，S.和C.Lonvick，编辑，“安全外壳（SSH）协议分配编号”，RFC 4250，DOI 10.17487/RFC4250，2006年1月<https://www.rfc-editor.org/info/rfc4250>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4251]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，DOI 10.17487/RFC4251，2006年1月<https://www.rfc-editor.org/info/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4252]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，DOI 10.17487/RFC4252，2006年1月<https://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<https://www.rfc-editor.org/info/rfc4253>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[RFC4254]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）连接协议”，RFC 4254，DOI 10.17487/RFC4254，2006年1月<https://www.rfc-editor.org/info/rfc4254>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[IANA-KE] IANA, "Key Exchange Method Names", <https://www.iana.org/assignments/ssh-parameters/>.
[IANA-KE]IANA，“密钥交换方法名称”<https://www.iana.org/assignments/ssh-parameters/>.
[IANA-M] IANA, "Message Numbers", <https://www.iana.org/assignments/ssh-parameters/>.
[IANA-M]IANA，“消息编号”<https://www.iana.org/assignments/ssh-parameters/>.
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol", RFC 8332, DOI 10.17487/RFC8332, March 2018, <https://www.rfc-editor.org/info/rfc8332>.
[RFC8332]Bider，D.，“在安全外壳（SSH）协议中使用具有SHA-256和SHA-512的RSA密钥”，RFC 8332，DOI 10.17487/RFC8332，2018年3月<https://www.rfc-editor.org/info/rfc8332>.
[WINADMIN] Microsoft, "How to launch a process as a Full Administrator when UAC is enabled?", March 2013, <https://blogs.msdn.microsoft.com/winsdk/2013/03/22/ how-to-launch-a-process-as-a-full-administrator-when-uac-is-enabled/>.
[WINADMIN]Microsoft，“启用UAC时如何以完全管理员身份启动流程？”，2013年3月<https://blogs.msdn.microsoft.com/winsdk/2013/03/22/ how-to-launch-a-process-as-a-full-administrator-when-uac-is-enabled/>。
[WINTOKEN] Microsoft, "TOKEN_ELEVATION_TYPE enumeration", <https://msdn.microsoft.com/en-us/library/windows/desktop/ bb530718.aspx>.
[WINTOKEN]Microsoft，“令牌类型枚举”<https://msdn.microsoft.com/en-us/library/windows/desktop/ bb530718.aspx>。
Acknowledgments
致谢
Thanks to Markus Friedl and Damien Miller for comments and initial implementation. Thanks to Peter Gutmann, Roumen Petrov, Mark D. Baushke, Daniel Migault, Eric Rescorla, Matthew A. Miller, Mirja Kuehlewind, Adam Roach, Spencer Dawkins, Alexey Melnikov, and Ben Campbell for reviews and feedback.
感谢Markus Friedl和Damien Miller的评论和初步实施。感谢Peter Gutmann、Roumen Petrov、Mark D.Baushke、Daniel Migault、Eric Rescorla、Matthew A.Miller、Mirja Kuehlewind、Adam Roach、Spencer Dawkins、Alexey Melnikov和Ben Campbell的评论和反馈。
Author's Address
作者地址
Denis Bider Bitvise Limited 4105 Lombardy Court Colleyville, TX 76034 United States of America
Denis Bider Bitvise Limited 4105 Lombardy Court Colleyville，德克萨斯州76034美利坚合众国
Email: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/
Email: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/