Network Working Group J. Hutzelman
Request for Comments: 4462 CMU
Category: Standards Track J. Salowey
Cisco Systems
J. Galbraith
Van Dyke Technologies, Inc.
V. Welch
U Chicago / ANL
May 2006
Network Working Group J. Hutzelman
Request for Comments: 4462 CMU
Category: Standards Track J. Salowey
Cisco Systems
J. Galbraith
Van Dyke Technologies, Inc.
V. Welch
U Chicago / ANL
May 2006
Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
安全Shell（SSH）协议的通用安全服务应用程序接口（GSS-API）身份验证和密钥交换
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 protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
安全外壳协议（SSH）是一种用于在不安全的网络上进行安全远程登录和其他安全网络服务的协议。
The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.
通用安全服务应用程序接口（GSS-API）以独立于机制的方式向调用者提供安全服务。
This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.
本备忘录描述了在SSH中使用GSS-API进行身份验证和密钥交换的方法。它定义了一个SSH用户身份验证方法，该方法使用指定的GSS-API机制对用户进行身份验证，以及一系列SSH密钥交换方法，这些方法使用GSS-API对Diffie-Hellman密钥交换进行身份验证。
This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange.
此备忘录还定义了一种新的主机公钥算法，该算法可在不需要使用主机公钥进行任何操作时使用，以及一种新的用户身份验证方法，该方法允许将授权名称与任何身份验证结合使用，该身份验证是基于GSS API的密钥交换的副作用。
Table of Contents
目录
1. Introduction ....................................................3
1.1. SSH Terminology ............................................3
1.2. Key Words ..................................................3
2. GSS-API-Authenticated Diffie-Hellman Key Exchange ...............3
2.1. Generic GSS-API Key Exchange ...............................4
2.2. Group Exchange ............................................10
2.3. gss-group1-sha1-* .........................................11
2.4. gss-group14-sha1-* ........................................12
2.5. gss-gex-sha1-* ............................................12
2.6. Other GSS-API Key Exchange Methods ........................12
3. GSS-API User Authentication ....................................13
3.1. GSS-API Authentication Overview ...........................13
3.2. Initiating GSS-API Authentication .........................13
3.3. Initial Server Response ...................................14
3.4. GSS-API Session ...........................................15
3.5. Binding Encryption Keys ...................................16
3.6. Client Acknowledgement ....................................16
3.7. Completion ................................................17
3.8. Error Status ..............................................17
3.9. Error Token ...............................................18
4. Authentication Using GSS-API Key Exchange ......................19
5. Null Host Key Algorithm ........................................20
6. Summary of Message Numbers .....................................21
7. GSS-API Considerations .........................................22
7.1. Naming Conventions ........................................22
7.2. Channel Bindings ..........................................22
7.3. SPNEGO ....................................................23
8. IANA Considerations ............................................24
9. Security Considerations ........................................24
10. Acknowledgements ..............................................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
1. Introduction ....................................................3
1.1. SSH Terminology ............................................3
1.2. Key Words ..................................................3
2. GSS-API-Authenticated Diffie-Hellman Key Exchange ...............3
2.1. Generic GSS-API Key Exchange ...............................4
2.2. Group Exchange ............................................10
2.3. gss-group1-sha1-* .........................................11
2.4. gss-group14-sha1-* ........................................12
2.5. gss-gex-sha1-* ............................................12
2.6. Other GSS-API Key Exchange Methods ........................12
3. GSS-API User Authentication ....................................13
3.1. GSS-API Authentication Overview ...........................13
3.2. Initiating GSS-API Authentication .........................13
3.3. Initial Server Response ...................................14
3.4. GSS-API Session ...........................................15
3.5. Binding Encryption Keys ...................................16
3.6. Client Acknowledgement ....................................16
3.7. Completion ................................................17
3.8. Error Status ..............................................17
3.9. Error Token ...............................................18
4. Authentication Using GSS-API Key Exchange ......................19
5. Null Host Key Algorithm ........................................20
6. Summary of Message Numbers .....................................21
7. GSS-API Considerations .........................................22
7.1. Naming Conventions ........................................22
7.2. Channel Bindings ..........................................22
7.3. SPNEGO ....................................................23
8. IANA Considerations ............................................24
9. Security Considerations ........................................24
10. Acknowledgements ..............................................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
This document describes the methods used to perform key exchange and user authentication in the Secure Shell protocol using the GSS-API. To do this, it defines a family of key exchange methods, two user authentication methods, and a new host key algorithm. These definitions allow any GSS-API mechanism to be used with the Secure Shell protocol.
本文档描述了使用GSS-API在Secure Shell协议中执行密钥交换和用户身份验证的方法。为此，它定义了一系列密钥交换方法、两种用户身份验证方法和一种新的主机密钥算法。这些定义允许任何GSS-API机制与Secure Shell协议一起使用。
This document should be read only after reading the documents describing the SSH protocol architecture [SSH-ARCH], transport layer protocol [SSH-TRANSPORT], and user authentication protocol [SSH-USERAUTH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
只有在阅读了描述SSH协议体系结构[SSH-ARCH]、传输层协议[SSH-transport]和用户身份验证协议[SSH-USERAUTH]的文档后，才能阅读本文档。本文档免费使用架构（architecture）文档中的术语和符号，无需参考或进一步解释。
The data types used in the packets are defined in the SSH architecture document [SSH-ARCH]. It is particularly important to note the definition of string allows binary content.
数据包中使用的数据类型在SSH体系结构文档[SSH-ARCH]中定义。特别重要的是要注意字符串的定义允许二进制内容。
The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this service name is an SSH service name and has no relationship to GSS-API service names. Currently, the only defined service name is "ssh-connection", which refers to the SSH connection protocol [SSH-CONNECT].
SSH_MSG_USERAUTH_请求包引用一个服务；此服务名称是SSH服务名称，与GSS-API服务名称没有关系。目前，唯一定义的服务名称是“ssh连接”，它指的是ssh连接协议[ssh-CONNECT]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
This section defines a class of key exchange methods that combine the Diffie-Hellman key exchange from Section 8 of [SSH-TRANSPORT] with mutual authentication using GSS-API.
本节定义了一类密钥交换方法，这些方法将[SSH-TRANSPORT]第8节中的Diffie-Hellman密钥交换与使用GSS-API的相互身份验证相结合。
Since the GSS-API key exchange methods described in this section do not require the use of public key signature or encryption algorithms, they MAY be used with any host key algorithm, including the "null" algorithm described in Section 5.
由于本节中描述的GSS-API密钥交换方法不需要使用公钥签名或加密算法，因此它们可以与任何主机密钥算法一起使用，包括第5节中描述的“null”算法。
The following symbols are used in this description:
本说明中使用了以下符号：
o C is the client, and S is the server
o C是客户端，S是服务器
o p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup
o p是大安全素数，g是GF（p）子群的生成元，q是子群的阶
o V_S is S's version string, and V_C is C's version string
o V_S是S的版本字符串，V_C是C的版本字符串
o I_C is C's KEXINIT message, and I_S is S's KEXINIT message
o I_C是C的KEXINIT消息，I_s是s的KEXINIT消息
1. C generates a random number x (1 < x < q) and computes e = g^x mod p.
1. C生成一个随机数x（1<x<q）并计算e=g^x mod p。
2. C calls GSS_Init_sec_context(), using the most recent reply token received from S during this exchange, if any. For this call, the client MUST set mutual_req_flag to "true" to request that mutual authentication be performed. It also MUST set integ_req_flag to "true" to request that per-message integrity protection be supported for this context. In addition, deleg_req_flag MAY be set to "true" to request access delegation, if requested by the user. Since the key exchange process authenticates only the host, the setting of anon_req_flag is immaterial to this process. If the client does not support the "gssapi-keyex" user authentication method described in Section 4, or does not intend to use that method in conjunction with the GSS-API context established during key exchange, then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY be set to true if the client wishes to hide its identity. Since the key exchange process will involve the exchange of only a single token once the context has been established, it is not necessary that the GSS-API context support detection of replayed or out-of-sequence tokens. Thus, replay_det_req_flag and sequence_req_flag need not be set for this process. These flags SHOULD be set to "false".
2. C调用GSS_Init_sec_context（），使用在此交换期间从S接收的最新应答令牌（如果有）。对于此调用，客户端必须将mutual_req_标志设置为“true”，以请求执行相互身份验证。它还必须将integ_req_标志设置为“true”，以请求在此上下文中支持每条消息的完整性保护。此外，如果用户请求，deleg_req_标志可以设置为“true”以请求访问委派。由于密钥交换过程仅对主机进行身份验证，因此anon_req_标志的设置对此过程并不重要。如果客户端不支持第4节中描述的“gssapi keyex”用户身份验证方法，或者不打算将该方法与密钥交换期间建立的GSS-API上下文结合使用，则anon_req_标志应设置为“true”。否则，如果客户端希望隐藏其身份，则此标志可能会设置为true。一旦建立了交换令牌的上下文，就不需要对其进行检测，因为交换令牌的上下文只需要对GSS进行检测。因此，不需要为此过程设置replay_det_req_标志和sequence_req_标志。这些标志应设置为“false”。
* If the resulting major_status code is GSS_S_COMPLETE and the mutual_state flag is not true, then mutual authentication has not been established, and the key exchange MUST fail.
* 如果生成的主要_状态代码为GSS_S_COMPLETE且相互_状态标志不为true，则相互身份验证尚未建立，密钥交换必须失败。
* If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available, and the key exchange MUST fail.
* 如果生成的主要_状态代码为GSS_S_COMPLETE且integ_avail标志不为true，则每条消息的完整性保护不可用，密钥交换必须失败。
* If the resulting major_status code is GSS_S_COMPLETE and both the mutual_state and integ_avail flags are true, the resulting output token is sent to S.
* 如果生成的主要_状态代码为GSS_S_COMPLETE，并且相互_状态和积分可用标志均为true，则生成的输出令牌将发送到S。
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the output_token is sent to S, which will reply with a new token to be provided to GSS_Init_sec_context().
* 如果生成的主要_状态代码是GSS_S_CONTINUE_NEEDED，则输出_令牌将发送到S，S将用提供给GSS_Init_sec_context（）的新令牌进行回复。
* The client MUST also include "e" with the first message it sends to the server during this process; if the server receives more than one "e" or none at all, the key exchange fails.
* 客户端在此过程中发送给服务器的第一条消息中还必须包含“e”；如果服务器收到多个“e”或根本没有，则密钥交换失败。
* It is an error if the call does not produce a token of non-zero length to be sent to the server. In this case, the key exchange MUST fail.
* 如果调用未生成要发送到服务器的非零长度令牌，则为错误。在这种情况下，密钥交换必须失败。
3. S calls GSS_Accept_sec_context(), using the token received from C.
3. S使用从C接收的令牌调用GSS_Accept_sec_context（）。
* If the resulting major_status code is GSS_S_COMPLETE and the mutual_state flag is not true, then mutual authentication has not been established, and the key exchange MUST fail.
* 如果生成的主要_状态代码为GSS_S_COMPLETE且相互_状态标志不为true，则相互身份验证尚未建立，密钥交换必须失败。
* If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available, and the key exchange MUST fail.
* 如果生成的主要_状态代码为GSS_S_COMPLETE且integ_avail标志不为true，则每条消息的完整性保护不可用，密钥交换必须失败。
* If the resulting major_status code is GSS_S_COMPLETE and both the mutual_state and integ_avail flags are true, then the security context has been established, and processing continues with step 4.
* 如果生成的主要_状态代码为GSS_S_COMPLETE，并且相互_状态和积分可用标志均为true，则安全上下文已建立，处理将继续执行步骤4。
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED, then the output token is sent to C, and processing continues with step 2.
* 如果生成的主要_状态代码是GSS_S_CONTINUE_NEEDED，则输出令牌被发送到C，处理继续执行步骤2。
* If the resulting major_status code is GSS_S_COMPLETE, but a non-zero-length reply token is returned, then that token is sent to the client.
* 如果生成的主要_状态代码是GSS_S_COMPLETE，但返回了非零长度的应答令牌，则该令牌将被发送到客户端。
4. S generates a random number y (0 < y < q) and computes f = g^y mod p. It computes K = e ^ y mod p, and H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K). It then calls GSS_GetMIC() to obtain a GSS-API message integrity code for H. S then sends f and the message integrity code (MIC) to C.
4. S生成一个随机数y（0<y<q）并计算f=g^y mod p。它计算K=e^y mod p，H=hash（V|u C|V|u S|I|u S|K|u S|e|f|K）。然后它调用GSS_GetMIC（）来获取H.S的GSS-API消息完整性代码。然后将f和消息完整性代码（MIC）发送给C。
5. This step is performed only (1) if the server's final call to GSS_Accept_sec_context() produced a non-zero-length final reply token to be sent to the client and (2) if no previous call by the client to GSS_Init_sec_context() has resulted in a major_status of GSS_S_COMPLETE. Under these conditions, the client makes an
5. 仅当（1）服务器对GSS_Accept_sec_context（）的最终调用生成了一个非零长度的最终应答令牌以发送给客户端时，以及（2）如果客户端先前对GSS_Init_sec_context（）的调用未导致GSS_sec_COMPLETE（）的主要_状态，则执行此步骤。在这些情况下，客户会做出
additional call to GSS_Init_sec_context() to process the final reply token. This call is made exactly as described above. However, if the resulting major_status is anything other than GSS_S_COMPLETE, or a non-zero-length token is returned, it is an error and the key exchange MUST fail.
对GSS_Init_sec_context（）的附加调用，以处理最终应答令牌。此呼叫完全按照上述方式进行。但是，如果生成的MAJUR_状态不是GSS_S_COMPLETE，或者返回非零长度令牌，则这是一个错误，密钥交换必须失败。
6. C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K). It then calls GSS_VerifyMIC() to verify that the MIC sent by S matches H. If the MIC is not successfully verified, the key exchange MUST fail.
6. C计算K=f^x mod p，H=hash（V|u C | V|u S | I|u S | K|u S | e | f | K）。然后调用GSS_VerifyMIC（）以验证S发送的麦克风是否与H匹配。如果麦克风未成功验证，则密钥交换必须失败。
Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails.
任何一方不得发送或接受不在[1，p-1]范围内的e或f值。如果违反此条件，则密钥交换失败。
If any call to GSS_Init_sec_context() or GSS_Accept_sec_context() returns a major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or any other GSS-API call returns a major_status other than GSS_S_COMPLETE, the key exchange fails. In this case, several mechanisms are available for communicating error information to the peer before terminating the connection as required by [SSH-TRANSPORT]:
如果对GSS_Init_sec_context（）或GSS_Accept_sec_context（）的任何调用返回除GSS_S_COMPLETE或GSS_CONTINUE_NEEDED之外的主要_状态，或者任何其他GSS-API调用返回除GSS_S_COMPLETE之外的主要_状态，则密钥交换失败。在这种情况下，有几种机制可用于根据[SSH-TRANSPORT]的要求在终止连接之前将错误信息传递给对等方：
o If the key exchange fails due to any GSS-API error on the server (including errors returned by GSS_Accept_sec_context()), the server MAY send a message informing the client of the details of the error. In this case, if an error token is also sent (see below), then this message MUST be sent before the error token.
o 如果由于服务器上的任何GSS-API错误（包括GSS_Accept_sec_context（）返回的错误）导致密钥交换失败，服务器可能会发送一条消息，通知客户端错误的详细信息。在这种情况下，如果还发送了错误令牌（请参见下文），则必须在发送错误令牌之前发送此消息。
o If the key exchange fails due to a GSS-API error returned from the server's call to GSS_Accept_sec_context(), and an "error token" is also returned, then the server SHOULD send the error token to the client to allow completion of the GSS security exchange.
o 如果由于服务器调用GSS_Accept_sec_context（）返回的GSS-API错误导致密钥交换失败，并且还返回了“错误令牌”，则服务器应将错误令牌发送给客户端，以允许完成GSS安全交换。
o If the key exchange fails due to a GSS-API error returned from the client's call to GSS_Init_sec_context(), and an "error token" is also returned, then the client SHOULD send the error token to the server to allow completion of the GSS security exchange.
o 如果由于客户端调用GSS_Init_sec_context（）返回的GSS-API错误导致密钥交换失败，并且还返回了“错误令牌”，则客户端应将错误令牌发送到服务器，以允许完成GSS安全交换。
As noted in Section 9, it may be desirable under site security policy to obscure information about the precise nature of the error; thus, it is RECOMMENDED that implementations provide a method to suppress these messages as a matter of policy.
如第9节所述，根据现场安全政策，可能需要掩盖错误确切性质的信息；因此，建议实现提供一种抑制这些消息的方法，作为一种策略。
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 group used for Diffie-Hellman key exchange and the underlying GSS-API mechanism are also defined by the method name.
这是通过以下消息实现的。计算交换哈希的哈希算法由方法名定义，称为哈希。用于Diffie-Hellman密钥交换的组和底层GSS-API机制也由方法名称定义。
After the client's first call to GSS_Init_sec_context(), it sends the following:
客户端第一次调用GSS_Init_sec_context（）后，将发送以下内容：
byte SSH_MSG_KEXGSS_INIT string output_token (from GSS_Init_sec_context()) mpint e
字节SSH_MSG_KEXGSS_INIT string output_token（来自GSS_INIT_sec_context（））mpint e
Upon receiving the SSH_MSG_KEXGSS_INIT message, the server MAY send the following message, prior to any other messages, to inform the client of its host key.
在接收到SSH_MSG_KEXGSS_INIT消息后，服务器可以在发送任何其他消息之前发送以下消息，以通知客户端其主机密钥。
byte SSH_MSG_KEXGSS_HOSTKEY string server public host key and certificates (K_S)
字节SSH_MSG_KEXGSS_主机密钥字符串服务器公共主机密钥和证书（K_S）
Since this key exchange method does not require the host key to be used for any encryption operations, this message is OPTIONAL. If the "null" host key algorithm described in Section 5 is used, this message MUST NOT be sent. If this message is sent, the server public host key(s) and/or certificate(s) in this message are encoded as a single string, in the format specified by the public key type in use (see [SSH-TRANSPORT], Section 6.6).
由于此密钥交换方法不要求主机密钥用于任何加密操作，因此此消息是可选的。如果使用第5节中描述的“null”主机密钥算法，则不得发送此消息。如果发送此消息，则此消息中的服务器公用主机密钥和/或证书将以使用中的公钥类型指定的格式编码为单个字符串（请参阅[SSH-TRANSPORT]，第6.6节）。
In traditional SSH deployments, host keys are normally expected to change infrequently, and there is often no mechanism for validating host keys not already known to the client. As a result, the use of a new host key by an already-known host is usually considered an indication of a possible man-in-the-middle attack, and clients often present strong warnings and/or abort the connection in such cases.
在传统的SSH部署中，主机密钥通常不会经常更改，并且通常没有机制来验证客户端还不知道的主机密钥。因此，已知主机使用新主机密钥通常被视为可能存在中间人攻击的迹象，在这种情况下，客户端通常会发出强烈警告和/或中断连接。
By contrast, when GSS-API-based key exchange is used, host keys sent via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as part of the GSS-API key exchange, even when previously unknown to the client. Further, in environments in which GSS-API-based key exchange is used heavily, it is possible and even likely that host keys will change much more frequently and/or without advance warning.
相反，当使用基于GSS API的密钥交换时，通过SSH_MSG_KEXGSS_HOSTKEY消息发送的主机密钥作为GSS-API密钥交换的一部分进行身份验证，即使客户端以前不知道。此外，在大量使用基于GSS API的密钥交换的环境中，主机密钥可能会更频繁地更改和/或在没有预先警告的情况下更改。
Therefore, when a new key for an already-known host is received via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue strong warnings or abort the connection, provided the GSS-API-based key exchange succeeds.
因此，当通过SSH_MSG_KEXGSS_HOSTKEY消息接收到已知主机的新密钥时，如果基于GSS API的密钥交换成功，客户端不应发出强烈警告或中止连接。
In order to facilitate key re-exchange after the user's GSS-API credentials have expired, client implementations SHOULD store host keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the session, even when such keys are not stored for long-term use.
为了便于在用户的GSS-API凭据过期后重新交换密钥，客户端实现应在会话期间存储通过SSH_MSG_KEXGSS_HOSTKEY接收的主机密钥，即使这些密钥不是为长期使用而存储的。
Each time the server's call to GSS_Accept_sec_context() returns a major_status code of GSS_S_CONTINUE_NEEDED, it sends the following reply to the client:
每次服务器调用GSS_Accept_sec_context（）返回所需GSS_s_CONTINUE_的主要_状态代码时，它都会向客户端发送以下回复：
byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Accept_sec_context())
字节SSH_MSG_KEXGSS_CONTINUE string output_token（来自GSS_Accept_sec_context（））
If the client receives this message after a call to GSS_Init_sec_context() has returned a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail.
如果客户端在调用GSS_Init_sec_context（）返回GSS_S_COMPLETE的主要_状态代码后收到此消息，则发生协议错误，密钥交换必须失败。
Each time the client receives the message described above, it makes another call to GSS_Init_sec_context(). It then sends the following:
每次客户端收到上述消息时，都会再次调用GSS_Init_sec_context（）。然后，它发送以下信息：
byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Init_sec_context())
字节SSH_MSG_KEXGSS_CONTINUE string output_token（来自GSS_Init_sec_context（））
The server and client continue to trade these two messages as long as the server's calls to GSS_Accept_sec_context() result in major_status codes of GSS_S_CONTINUE_NEEDED. When a call results in a major_status code of GSS_S_COMPLETE, it sends one of two final messages.
只要服务器对GSS_Accept_sec_context（）的调用导致需要GSS_s_continue_的主要_状态代码，服务器和客户端就会继续交换这两条消息。当一个调用产生GSS_S_COMPLETE的主_状态代码时，它会发送两条最终消息中的一条。
If the server's final call to GSS_Accept_sec_context() (resulting in a major_status code of GSS_S_COMPLETE) returns a non-zero-length token to be sent to the client, it sends the following:
如果服务器对GSS_Accept_sec_context（）的最后调用（导致GSS_s_COMPLETE的主_状态代码）返回一个非零长度令牌以发送给客户端，则它将发送以下内容：
byte SSH_MSG_KEXGSS_COMPLETE mpint f string per_msg_token (MIC of H) boolean TRUE string output_token (from GSS_Accept_sec_context())
字节SSH\u MSG\u KEXGSS\u每个\u MSG\u令牌（H的MIC）完整mpint f字符串布尔真字符串输出\u令牌（来自GSS\u Accept\u sec\u context（））
If the client receives this message after a call to GSS_Init_sec_context() has returned a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail.
如果客户端在调用GSS_Init_sec_context（）返回GSS_S_COMPLETE的主要_状态代码后收到此消息，则发生协议错误，密钥交换必须失败。
If the server's final call to GSS_Accept_sec_context() (resulting in a major_status code of GSS_S_COMPLETE) returns a zero-length token or no token at all, it sends the following:
如果服务器对GSS_Accept_sec_context（）的最后调用（导致GSS_s_COMPLETE的主_状态代码）返回零长度令牌或根本不返回令牌，则它将发送以下消息：
byte SSH_MSG_KEXGSS_COMPLETE mpint f string per_msg_token (MIC of H) boolean FALSE
字节SSH\u MSG\u KEXGSS\u每个符号的字符串完整mpint f（H的MIC）布尔值为FALSE
If the client receives this message when no call to GSS_Init_sec_context() has yet resulted in a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail.
如果客户端在没有调用GSS_Init_sec_context（）导致GSS_S_COMPLETE的主要_状态代码时收到此消息，则会发生协议错误，密钥交换必须失败。
If either the client's call to GSS_Init_sec_context() or the server's call to GSS_Accept_sec_context() returns an error status and produces an output token (called an "error token"), then the following SHOULD be sent to convey the error information to the peer:
如果客户端对GSS_Init_sec_context（）的调用或服务器对GSS_Accept_sec_context（）的调用返回错误状态并生成输出令牌（称为“错误令牌”），则应发送以下消息以将错误信息传递给对等方：
byte SSH_MSG_KEXGSS_CONTINUE string error_token
字节SSH\u MSG\u KEXGSS\u继续字符串错误\u令牌
If a server sends both this message and an SSH_MSG_KEXGSS_ERROR message, the SSH_MSG_KEXGSS_ERROR message MUST be sent first, to allow clients to record and/or display the error information before processing the error token. This is important because a client processing an error token will likely disconnect without reading any further messages.
如果服务器同时发送此消息和SSH_MSG_KEXGSS_错误消息，则必须首先发送SSH_MSG_KEXGSS_错误消息，以允许客户端在处理错误令牌之前记录和/或显示错误信息。这一点很重要，因为处理错误令牌的客户端可能会断开连接而不读取任何进一步的消息。
In the event of a GSS-API error on the server, the server MAY send the following message before terminating the connection:
如果服务器上发生GSS-API错误，服务器可能会在终止连接之前发送以下消息：
byte SSH_MSG_KEXGSS_ERROR uint32 major_status uint32 minor_status string message string language tag
字节SSH\u MSG\u KEXGSS\u错误uint32主要\u状态uint32次要\u状态字符串消息字符串语言标记
The message text MUST be encoded in the UTF-8 encoding described in [UTF8]. Language tags are those described in [LANGTAG]. Note that the message text may contain multiple lines separated by carriage return-line feed (CRLF) sequences. Application developers should take this into account when displaying these messages.
消息文本必须按照[UTF8]中所述的UTF-8编码进行编码。语言标记是[LANGTAG]中描述的标记。请注意，消息文本可能包含由回车换行符（CRLF）序列分隔的多行。应用程序开发人员在显示这些消息时应该考虑到这一点。
The hash H is computed as the HASH hash of the concatenation of the following:
散列H被计算为以下各项的串联的散列：
string V_C, the client's version string (CR, NL excluded) string V_S, the server's version string (CR, NL 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，NL除外）string V_s、服务器的版本字符串（CR，NL除外）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. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the server or received by the client, then the empty string is used in place of K_S when computing the exchange hash.
此值称为交换哈希，用于验证密钥交换。交换哈希应该保密。如果服务器未发送或客户端未接收到SSH_MSG_KEXGSS_HOSTKEY消息，则在计算exchange哈希时将使用空字符串代替K_S。
The GSS_GetMIC call MUST be applied over H, not the original data.
GSS_GetMIC调用必须应用于H，而不是原始数据。
This section describes a modification to the generic GSS-API-authenticated Diffie-Hellman key exchange to allow the negotiation of the group to be used, using a method based on that described in [GROUP-EXCHANGE].
本节描述了对通用GSS API认证Diffie-Hellman密钥交换的修改，以允许使用基于[group-exchange]中所述方法的组协商。
The server keeps a list of safe primes and corresponding generators that it can select from. These are chosen as described in Section 3 of [GROUP-EXCHANGE]. The client requests a modulus from the server, indicating the minimum, maximum, and preferred sizes; the server responds with a suitable modulus and generator. The exchange then proceeds as described in Section 2.1 above.
服务器保存一个安全素数和相应生成器的列表，可以从中进行选择。按照[GROUP-EXCHANGE]第3节中的说明选择。客户端从服务器请求模数，指示最小、最大和首选尺寸；服务器使用适当的模数和生成器进行响应。然后，按照上述第2.1节的规定进行交易。
This description uses the following symbols, in addition to those defined above:
除了上面定义的符号外，本说明还使用以下符号：
o n is the size of the modulus p in bits that the client would like to receive from the server
o n是客户端希望从服务器接收的模数p的大小（以位为单位）
o min and max are the minimal and maximal sizes of p in bits that are acceptable to the client
o min和max是客户端可以接受的p的最小和最大大小（以位为单位）
1. C sends "min || n || max" to S, indicating the minimal acceptable group size, the preferred size of the group, and the maximal group size in bits the client will accept.
1. C向S发送“min | | n | | max”，指示最小可接受组大小、组的首选大小以及客户端将接受的最大组大小（以位为单位）。
2. S finds a group that best matches the client's request, and sends "p || g" to C.
2. S找到最符合客户请求的组，并将“p | | g”发送给C。
3. The exchange proceeds as described in Section 2.1 above, beginning with step 1, except that the exchange hash is computed as described below.
3. 交换按照上文第2.1节所述进行，从步骤1开始，交换散列的计算如下所述。
Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.
服务器和客户端应支持模数长度为k位的组，其中1024<=k<=8192。最小值和最大值的建议值分别为1024和8192。
This is implemented using the following messages, in addition to those described above:
除上述消息外，还使用以下消息实现：
First, the client sends:
首先，客户端发送：
byte SSH_MSG_KEXGSS_GROUPREQ uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server should send uint32 max, maximal size in bits of an acceptable group
字节SSH_MSG_KEXGSS_GROUPREQ uint32 min，可接受组uint32 n的最小位大小，服务器应发送的组的首选位大小uint32 max，可接受组的最大位大小
The server responds with:
服务器响应为：
byte SSH_MSG_KEXGSS_GROUP mpint p, safe prime mpint g, generator for subgroup in GF(p)
字节SSH_MSG_KEXGSS_组mpint p，安全素数mpint g，GF（p）中子组的生成器
This is followed by the message exchange described above in Section 2.1, except that the exchange hash H is computed as the HASH hash of the concatenation of the following:
随后是上文第2.1节所述的消息交换，但交换散列H被计算为下列串联的散列：
string V_C, the client's version string (CR, NL excluded) string V_S, the server's version string (CR, NL 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 uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server should send uint32 max, maximal size in bits of an acceptable group mpint p, safe prime mpint g, generator for subgroup in GF(p) mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret
字符串V_C、客户端的版本字符串（CR，NL除外）字符串V_s、服务器的版本字符串（CR，NL除外）字符串I_C、客户端的SSH_MSG_KEXINIT字符串I_的有效负载、服务器的SSH_MSG_KEXINIT字符串K_s的有效负载、主机密钥uint32 min、可接受组uint32 n的最小位大小，服务器应发送的组的首选大小（以位为单位）uint32 max、可接受组的最大大小（以位为单位）mpint p、安全素数mpint g、GF（p）mpint e中的子组生成器、客户端发送的交换值mpint f、服务器发送的交换值mpint K、共享密钥
Each of these methods specifies GSS-API-authenticated Diffie-Hellman key exchange as described in Section 2.1 with SHA-1 as HASH, and the group defined in Section 8.1 of [SSH-TRANSPORT]. The method name for each method is the concatenation of the string "gss-group1-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 Distinguished Encoding Rules (DER) encoding [ASN1] of the underlying GSS-API mechanism's Object Identifier (OID). Base64 encoding is described in Section 6.8 of [MIME].
这些方法中的每一种都指定了GSS API认证的Diffie-Hellman密钥交换，如第2.1节所述，SHA-1作为散列，以及[SSH-TRANSPORT]第8.1节中定义的组。每个方法的方法名称是字符串“gss-group1-sha1-”与基础gss-API机制的对象标识符（OID）的ASN.1可分辨编码规则（DER）编码[ASN1]的MD5哈希[MD5]的Base64编码的串联。[MIME]的第6.8节描述了Base64编码。
Each and every such key exchange method is implicitly registered by this specification. The IESG is considered to be the owner of all such key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism.
每个这样的密钥交换方法都由本规范隐式注册。IESG被视为所有此类密钥交换方法的所有者；这并不意味着IESG被认为是底层GSS-API机制的所有者。
Each of these methods specifies GSS-API authenticated Diffie-Hellman key exchange as described in Section 2.1 with SHA-1 as HASH, and the group defined in Section 8.2 of [SSH-TRANSPORT]. The method name for each method is the concatenation of the string "gss-group14-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the underlying GSS-API mechanism's OID. Base64 encoding is described in Section 6.8 of [MIME].
这些方法中的每一种都指定了GSS-API认证的Diffie-Hellman密钥交换，如第2.1节所述，SHA-1作为散列，以及[SSH-TRANSPORT]第8.2节中定义的组。每个方法的方法名称是字符串“gss-group14-sha1-”与底层gss-API机制的OID的ASN.1 DER编码[ASN1]的MD5哈希[MD5]的Base64编码的串联。[MIME]的第6.8节描述了Base64编码。
Each and every such key exchange method is implicitly registered by this specification. The IESG is considered to be the owner of all such key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism.
每个这样的密钥交换方法都由本规范隐式注册。IESG被视为所有此类密钥交换方法的所有者；这并不意味着IESG被认为是底层GSS-API机制的所有者。
Each of these methods specifies GSS-API-authenticated Diffie-Hellman key exchange as described in Section 2.2 with SHA-1 as HASH. The method name for each method is the concatenation of the string "gss-gex-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the underlying GSS-API mechanism's OID. Base64 encoding is described in Section 6.8 of [MIME].
这些方法中的每一种都指定GSS API认证的Diffie-Hellman密钥交换，如第2.2节所述，SHA-1作为散列。每个方法的方法名都是字符串“gss-gex-sha1-”与基础gss-API机制OID的ASN.1 DER编码[ASN1]的MD5哈希[MD5]的Base64编码的串联。[MIME]的第6.8节描述了Base64编码。
Each and every such key exchange method is implicitly registered by this specification. The IESG is considered to be the owner of all such key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism.
每个这样的密钥交换方法都由本规范隐式注册。IESG被视为所有此类密钥交换方法的所有者；这并不意味着IESG被认为是底层GSS-API机制的所有者。
Key exchange method names starting with "gss-" are reserved for key exchange methods that conform to this document; in particular, for those methods that use the GSS-API-authenticated Diffie-Hellman key exchange algorithm described in Section 2.1, including any future methods that use different groups and/or hash functions. The intent is that the names for any such future methods be defined in a similar manner to that used in Section 2.3.
以“gss-”开头的密钥交换方法名称保留给符合本文件要求的密钥交换方法；特别是，对于使用第2.1节中描述的GSS API认证Diffie-Hellman密钥交换算法的方法，包括使用不同组和/或散列函数的任何未来方法。目的是以与第2.3节中使用的类似方式定义任何此类未来方法的名称。
This section describes a general-purpose user authentication method based on [GSSAPI]. It is intended to be run over the SSH user authentication protocol [SSH-USERAUTH].
本节介绍基于[GSSAPI]的通用用户身份验证方法。它打算通过SSH用户身份验证协议[SSH-USERAUTH]运行。
The authentication method name for this protocol is "gssapi-with-mic".
此协议的身份验证方法名称为“gssapi with mic”。
GSS-API authentication must maintain a context. Authentication begins when the client sends an SSH_MSG_USERAUTH_REQUEST, which specifies the mechanism OIDs the client supports.
GSS-API身份验证必须维护上下文。当客户端发送SSH\u MSG\u USERAUTH\u请求时，身份验证开始，该请求指定客户端支持的机制。
If the server supports any of the requested mechanism OIDs, the server sends an SSH_MSG_USERAUTH_GSSAPI_RESPONSE message containing the mechanism OID.
如果服务器支持任何请求的机制OID，则服务器将发送包含该机制OID的SSH_MSG_USERAUTH_GSSAPI_响应消息。
After the client receives SSH_MSG_USERAUTH_GSSAPI_RESPONSE, the client and server exchange SSH_MSG_USERAUTH_GSSAPI_TOKEN packets until the authentication mechanism either succeeds or fails.
客户端收到SSH_MSG_USERAUTH_GSSAPI_响应后，客户端和服务器交换SSH_MSG_USERAUTH_GSSAPI_令牌数据包，直到身份验证机制成功或失败。
If at any time during the exchange the client sends a new SSH_MSG_USERAUTH_REQUEST packet, the GSS-API context is completely discarded and destroyed, and any further GSS-API authentication MUST restart from the beginning.
如果在交换期间的任何时候，客户端发送新的SSH_MSG_USERAUTH_请求数据包，则GSS-API上下文将被完全丢弃和销毁，任何进一步的GSS-API身份验证都必须从头开始。
If the authentication succeeds and a non-empty user name is presented by the client, the SSH server implementation verifies that the user name is authorized based on the credentials exchanged in the GSS-API exchange. If the user name is not authorized, then the authentication MUST fail.
如果身份验证成功并且客户端提供了一个非空用户名，则SSH服务器实现将根据GSS-API交换中交换的凭据验证用户名是否经过授权。如果用户名未经授权，则身份验证必须失败。
The GSS-API authentication method is initiated when the client sends an SSH_MSG_USERAUTH_REQUEST:
当客户端发送SSH_MSG_USERAUTH_请求时，GSS-API身份验证方法将启动：
byte SSH_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding) string service name (in US-ASCII) string "gssapi-with-mic" (US-ASCII method name) uint32 n, the number of mechanism OIDs client supports string[n] mechanism OIDs
字节SSH_MSG_USERAUTH_请求字符串用户名（ISO-10646 UTF-8编码）字符串服务名称（US-ASCII）字符串“gssapi with mic”（US-ASCII方法名称）uint32 n，客户端支持字符串[n]机制OID的机制OID数
Mechanism OIDs are encoded according to the ASN.1 Distinguished Encoding Rules (DER), as described in [ASN1] and in Section 3.1 of
机制OID根据ASN.1可分辨编码规则（DER）进行编码，如[ASN1]和本规范第3.1节所述
[GSSAPI]. The mechanism OIDs MUST be listed in order of preference, and the server must choose the first mechanism OID on the list that it supports.
[GSSAPI]。机制OID必须按优先顺序列出，服务器必须选择其支持的列表中的第一个机制OID。
The client SHOULD send GSS-API mechanism OIDs only for mechanisms that are of the same priority, compared to non-GSS-API authentication methods. Otherwise, authentication methods may be executed out of order. Thus, the client could first send an SSH_MSG_USERAUTH_REQUEST for one GSS-API mechanism, then try public key authentication, and then try another GSS-API mechanism.
与非GSS API身份验证方法相比，客户端应仅为具有相同优先级的机制发送GSS-API机制OID。否则，身份验证方法可能会无序执行。因此，客户机可以首先为一个GSS-API机制发送SSH_MSG_USERAUTH_请求，然后尝试公钥身份验证，然后尝试另一个GSS-API机制。
If the server does not support any of the specified OIDs, the server MUST fail the request by sending an SSH_MSG_USERAUTH_FAILURE packet.
如果服务器不支持任何指定的OID，则服务器必须通过发送SSH_MSG_USERAUTH_失败数据包使请求失败。
The user name may be an empty string if it can be deduced from the results of the GSS-API authentication. If the user name is not empty, and the requested user does not exist, the server MAY disconnect or MAY send a bogus list of acceptable authentications but never accept any. This makes it possible for the server to avoid disclosing information about which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted.
如果可以从GSS-API身份验证的结果推断用户名，则用户名可能是空字符串。如果用户名不为空，并且请求的用户不存在，则服务器可能会断开连接，或者可能会发送虚假的可接受身份验证列表，但从不接受任何身份验证。这使得服务器可以避免披露有关存在哪些帐户的信息。在任何情况下，如果用户不存在，则不能接受身份验证请求。
Note that the 'user name' value is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the user name and determines whether the client is authorized based on his GSS-API credentials. In particular, the encoding used by the system for user names is a matter for the ssh server implementation. However, if the client reads the user name in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the user name to ISO-10646 UTF-8 before transmitting, and the server MUST convert the user name to the encoding used on that system for user names.
请注意，“用户名”值以ISO-10646 UTF-8编码。这取决于服务器如何解释用户名，并根据其GSS-API凭据确定是否授权客户端。特别是，系统对用户名使用的编码是ssh服务器实现的问题。但是，如果客户端以其他编码（例如ISO 8859-1-ISO拉丁语）读取用户名，则必须在传输之前将用户名转换为ISO-10646 UTF-8，并且服务器必须将用户名转换为该系统上用于用户名的编码。
Any normalization or other preparation of names is done by the ssh server based on the requirements of the system, and is outside the scope of SSH. SSH implementations which maintain private user databases SHOULD prepare user names as described by [SASLPREP].
名称的任何规范化或其他准备工作都是由ssh服务器根据系统的要求完成的，不在ssh的范围之内。维护私有用户数据库的SSH实现应该按照[SASLPREP]所述准备用户名。
The client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one.
客户端可以随时继续发送新的SSH_MSG_USERAUTH_请求消息，在这种情况下，服务器必须放弃以前的身份验证尝试，继续发送新的身份验证尝试。
The server responds to the SSH_MSG_USERAUTH_REQUEST with either an SSH_MSG_USERAUTH_FAILURE if none of the mechanisms are supported or with an SSH_MSG_USERAUTH_GSSAPI_RESPONSE as follows:
服务器响应SSH\u MSG\u USERAUTH\u请求时，如果不支持任何机制，则使用SSH\u MSG\u USERAUTH\u失败，或者使用SSH\u MSG\u USERAUTH\u GSSAPI\u响应，如下所示：
byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE string selected mechanism OID
字节SSH\u MSG\u USERAUTH\u GSSAPI\u响应字符串所选机制OID
The mechanism OID must be one of the OIDs sent by the client in the SSH_MSG_USERAUTH_REQUEST packet.
机制OID必须是客户端在SSH_MSG_USERAUTH_请求数据包中发送的OID之一。
Once the mechanism OID has been selected, the client will then initiate an exchange of one or more pairs of SSH_MSG_USERAUTH_GSSAPI_TOKEN packets. These packets contain the tokens produced from the 'GSS_Init_sec_context()' and 'GSS_Accept_sec_context()' calls. The actual number of packets exchanged is determined by the underlying GSS-API mechanism.
一旦选择了机制OID，客户端将启动一对或多对SSH_MSG_USERAUTH_GSSAPI_令牌数据包的交换。这些数据包包含从“GSS_Init_sec_context（）”和“GSS_Accept_sec_context（）”调用生成的令牌。交换的数据包的实际数量由底层GSS-API机制决定。
byte SSH_MSG_USERAUTH_GSSAPI_TOKEN string data returned from either GSS_Init_sec_context() or GSS_Accept_sec_context()
从GSS_Init_sec_context（）或GSS_Accept_sec_context（）返回的字节SSH_MSG_USERAUTH_GSSAPI_令牌字符串数据
If an error occurs during this exchange on server side, the server can terminate the method by sending an SSH_MSG_USERAUTH_FAILURE packet. If an error occurs on client side, the client can terminate the method by sending a new SSH_MSG_USERAUTH_REQUEST packet.
如果在服务器端的交换过程中发生错误，服务器可以通过发送SSH_MSG_USERAUTH_失败数据包来终止该方法。如果客户端发生错误，客户端可以通过发送新的SSH\u MSG\u USERAUTH\u请求数据包来终止该方法。
When calling GSS_Init_sec_context(), the client MUST set integ_req_flag to "true" to request that per-message integrity protection be supported for this context. In addition, deleg_req_flag MAY be set to "true" to request access delegation, if requested by the user.
调用GSS_Init_sec_context（）时，客户端必须将integ_req_标志设置为“true”，以请求此上下文支持每条消息的完整性保护。此外，如果用户请求，deleg_req_标志可以设置为“true”以请求访问委派。
Since the user authentication process by its nature authenticates only the client, the setting of mutual_req_flag is not needed for this process. This flag SHOULD be set to "false".
由于用户身份验证过程本质上只对客户端进行身份验证，因此此过程不需要设置mutual_req_标志。此标志应设置为“false”。
Since the user authentication process will involve the exchange of only a single token once the context has been established, it is not necessary that the context support detection of replayed or out-of-sequence tokens. Thus, the setting of replay_det_req_flag and sequence_req_flag are not needed for this process. These flags SHOULD be set to "false".
由于一旦建立了上下文，用户认证过程将仅涉及交换单个令牌，因此上下文不必支持检测重播或无序令牌。因此，该过程不需要设置replay_det_req_标志和sequence_req_标志。这些标志应设置为“false”。
Additional SSH_MSG_USERAUTH_GSSAPI_TOKEN messages are sent if and only if the calls to the GSS-API routines produce send tokens of non-zero length.
当且仅当对GSS-API例程的调用产生长度非零的发送令牌时，才会发送附加的SSH_MSG_USERAUTH_GSSAPI_令牌消息。
Any major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED SHOULD be a failure.
除所需的GSS_S_完成或GSS_继续之外的任何主要状态代码都应为故障。
In some cases, it is possible to obtain improved security by allowing access only if the client sends a valid message integrity code (MIC) binding the GSS-API context to the keys used for encryption and integrity protection of the SSH session. With this extra level of protection, a "man-in-the-middle" attacker who has convinced a client of his authenticity cannot then relay user authentication messages between the real client and server, thus gaining access to the real server. This additional protection is available when the negotiated GSS-API context supports per-message integrity protection, as indicated by the setting of the integ_avail flag on successful return from GSS_Init_sec_context() or GSS_Accept_sec_context().
在某些情况下，只有当客户端发送有效的消息完整性代码（MIC）将GSS-API上下文绑定到用于SSH会话加密和完整性保护的密钥时，才允许访问，从而可以提高安全性。有了这一额外的保护级别，“中间人”攻击者就无法在真实的客户端和服务器之间中继用户身份验证消息，从而获得对真实服务器的访问权。当协商的GSS-API上下文支持每消息完整性保护时，此附加保护可用，如从GSS_Init_sec_context（）或GSS_Accept_sec_context（）成功返回时设置integ_avail标志所示。
When the client's call to GSS_Init_sec_context() returns GSS_S_COMPLETE with the integ_avail flag set, the client MUST conclude the user authentication exchange by sending the following message:
当客户端对GSS_Init_sec_context（）的调用返回GSS_s_并带有integ_avail标志集时，客户端必须通过发送以下消息来结束用户身份验证交换：
byte SSH_MSG_USERAUTH_GSSAPI_MIC string MIC
字节SSH\u MSG\u USERAUTH\u GSSAPI\u麦克风字符串麦克风
This message MUST be sent only if GSS_Init_sec_context() returned GSS_S_COMPLETE. If a token is also returned, then the SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
只有当GSS_Init_sec_context（）返回GSS_S_COMPLETE时，才能发送此消息。如果还返回了一个令牌，则必须在该令牌之前发送SSH_MSG_USERAUTH_GSSAPI_令牌消息。
The contents of the MIC field are obtained by calling GSS_GetMIC() over the following, using the GSS-API context that was just established:
通过使用刚刚建立的GSS-API上下文，通过以下调用GSS_GetMIC（）来获取MIC字段的内容：
string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-with-mic"
字符串会话标识符字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务字符串“带麦克风的gssapi”
If this message is received by the server before the GSS-API context is fully established, the server MUST fail the authentication.
如果服务器在完全建立GSS-API上下文之前收到此消息，则服务器必须通过身份验证。
If this message is received by the server when the negotiated GSS-API context does not support per-message integrity protection, the server MUST fail the authentication.
如果当协商的GSS-API上下文不支持每条消息的完整性保护时，服务器收到此消息，则服务器必须使身份验证失败。
Some servers may wish to permit user authentication to proceed even when the negotiated GSS-API context does not support per-message integrity protection. In such cases, it is possible for the server
即使协商的GSS-API上下文不支持每消息完整性保护，某些服务器也可能希望允许用户身份验证继续进行。在这种情况下，服务器
to successfully complete the GSS-API method, while the client's last call to GSS_Init_sec_context() fails. If the server simply assumed success on the part of the client and completed the authentication service, it is possible that the client would fail to complete the authentication method, but not be able to retry other methods because the server had already moved on. To protect against this, a final message is sent by the client to indicate it has completed authentication.
要成功完成GSS-API方法，客户端最后一次调用GSS_Init_sec_context（）失败。如果服务器只是假设客户端成功并完成了身份验证服务，则客户端可能无法完成身份验证方法，但无法重试其他方法，因为服务器已经移动。为了防止出现这种情况，客户端将发送最后一条消息，指示它已完成身份验证。
When the client's call to GSS_Init_sec_context() returns GSS_S_COMPLETE with the integ_avail flag not set, the client MUST conclude the user authentication exchange by sending the following message:
当客户端调用GSS_Init_sec_context（）返回GSS_s_COMPLETE且未设置integ_avail标志时，客户端必须通过发送以下消息结束用户身份验证交换：
byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
字节SSH\u MSG\u USERAUTH\u GSSAPI\u交换完成
This message MUST be sent only if GSS_Init_sec_context() returned GSS_S_COMPLETE. If a token is also returned, then the SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
只有当GSS_Init_sec_context（）返回GSS_S_COMPLETE时，才能发送此消息。如果还返回了一个令牌，则必须在该令牌之前发送SSH_MSG_USERAUTH_GSSAPI_令牌消息。
If this message is received by the server before the GSS-API context is fully established, the server MUST fail the authentication.
如果服务器在完全建立GSS-API上下文之前收到此消息，则服务器必须通过身份验证。
If this message is received by the server when the negotiated GSS-API context supports per-message integrity protection, the server MUST fail the authentication.
如果当协商的GSS-API上下文支持每条消息的完整性保护时，服务器收到此消息，则服务器必须使身份验证失败。
It is a site policy decision for the server whether or not to permit authentication using GSS-API mechanisms and/or contexts that do not support per-message integrity protection. The server MAY fail the otherwise valid gssapi-with-mic authentication if per-message integrity protection is not supported.
是否允许使用不支持每消息完整性保护的GSS-API机制和/或上下文进行身份验证是服务器的站点策略决定。如果不支持每条消息的完整性保护，则服务器可能会使原本有效的gssapi和mic身份验证失败。
As with all SSH authentication methods, successful completion is indicated by an SSH_MSG_USERAUTH_SUCCESS if no other authentication is required, or an SSH_MSG_USERAUTH_FAILURE with the partial success flag set if the server requires further authentication. This packet SHOULD be sent immediately following receipt of the SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet.
与所有SSH身份验证方法一样，如果不需要其他身份验证，则通过SSH_MSG_USERAUTH_SUCCESS指示成功完成，如果服务器需要进一步身份验证，则通过SSH_MSG_USERAUTH_失败指示部分成功标志。此数据包应在收到SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE数据包后立即发送。
In the event that a GSS-API error occurs on the server during context establishment, the server MAY send the following message to inform the client of the details of the error before sending an SSH_MSG_USERAUTH_FAILURE message:
如果在建立上下文期间服务器上发生GSS-API错误，服务器可能会发送以下消息，在发送SSH_MSG_USERAUTH_失败消息之前，将错误的详细信息通知客户端：
byte SSH_MSG_USERAUTH_GSSAPI_ERROR uint32 major_status uint32 minor_status string message string language tag
字节SSH\U MSG\U USERAUTH\U GSSAPI\U错误uint32主要\U状态uint32次要\U状态字符串消息字符串语言标记
The message text MUST be encoded in the UTF-8 encoding described in [UTF8]. Language tags are those described in [LANGTAG]. Note that the message text may contain multiple lines separated by carriage return-line feed (CRLF) sequences. Application developers should take this into account when displaying these messages.
消息文本必须按照[UTF8]中所述的UTF-8编码进行编码。语言标记是[LANGTAG]中描述的标记。请注意，消息文本可能包含由回车换行符（CRLF）序列分隔的多行。应用程序开发人员在显示这些消息时应该考虑到这一点。
Clients receiving this message MAY log the error details and/or report them to the user. Any server sending this message MUST ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response.
接收此消息的客户端可以记录错误详细信息和/或向用户报告。发送此消息的任何服务器都必须忽略客户端在响应中发送的任何SSH_MSG_未实现。
In the event that, during context establishment, a client's call to GSS_Init_sec_context() or a server's call to GSS_Accept_sec_context() returns a token along with an error status, the resulting "error token" SHOULD be sent to the peer using the following message:
如果在上下文建立过程中，客户端对GSS_Init_sec_context（）的调用或服务器对GSS_Accept_sec_context（）的调用返回一个令牌以及错误状态，则应使用以下消息将生成的“错误令牌”发送给对等方：
byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK string error token
字节SSH\u MSG\u USERAUTH\u GSSAPI\u ERRTOK字符串错误令牌
This message implies that the authentication is about to fail, and is defined to allow the error token to be communicated without losing synchronization.
此消息表示身份验证即将失败，并定义为允许在不丢失同步的情况下通信错误令牌。
When a server sends this message, it MUST be followed by an SSH_MSG_USERAUTH_FAILURE message, which is to be interpreted as applying to the same authentication request. A client receiving this message SHOULD wait for the following SSH_MSG_USERAUTH_FAILURE message before beginning another authentication attempt.
当服务器发送此消息时，它后面必须跟着一条SSH_MSG_USERAUTH_失败消息，该消息将被解释为应用于相同的身份验证请求。接收此消息的客户端应等待以下SSH_MSG_USERAUTH_失败消息，然后再开始另一次身份验证尝试。
When a client sends this message, it MUST be followed by a new authentication request or by terminating the connection. A server receiving this message MUST NOT send an SSH_MSG_USERAUTH_FAILURE in reply, since such a message might otherwise be interpreted by a client as a response to the following authentication sequence.
当客户端发送此消息时，它后面必须跟着一个新的身份验证请求或终止连接。接收此消息的服务器不得发送SSH_MSG_USERAUTH_失败回复，因为这样的消息可能会被客户端解释为对以下身份验证序列的响应。
Any server sending this message MUST ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response. If a server sends both this message and an SSH_MSG_USERAUTH_GSSAPI_ERROR message, the SSH_MSG_USERAUTH_GSSAPI_ERROR message MUST be sent first, to allow the client to store and/or display the error status before processing the error token.
发送此消息的任何服务器都必须忽略客户端在响应中发送的任何SSH_MSG_未实现。如果服务器同时发送此消息和SSH_MSG_USERAUTH_GSSAPI_错误消息，则必须首先发送SSH_MSG_USERAUTH_GSSAPI_错误消息，以允许客户端在处理错误令牌之前存储和/或显示错误状态。
This section describes a user authentication method building on the framework described in [SSH-USERAUTH]. This method performs user authentication by making use of an existing GSS-API context established during key exchange.
本节介绍基于[SSH-USERAUTH]中所述框架构建的用户身份验证方法。此方法通过使用密钥交换期间建立的现有GSS-API上下文来执行用户身份验证。
The authentication method name for this protocol is "gssapi-keyex".
此协议的身份验证方法名称为“gssapi keyex”。
This method may be used only if the initial key exchange was performed using a GSS-API-based key exchange method defined in accordance with Section 2. The GSS-API context used with this method is always that established during an initial GSS-API-based key exchange. Any context established during key exchange for the purpose of rekeying MUST NOT be used with this method.
仅当初始密钥交换是使用根据第2节定义的基于GSS API的密钥交换方法执行时，才可使用此方法。与此方法一起使用的GSS-API上下文始终是在基于GSS API的初始密钥交换期间建立的上下文。在密钥交换过程中建立的任何上下文都不得用于此方法。
The server SHOULD include this user authentication method in the list of methods that can continue (in an SSH_MSG_USERAUTH_FAILURE) if the initial key exchange was performed using a GSS-API-based key exchange method and provides information about the user's identity that is useful to the server. It MUST NOT include this method if the initial key exchange was not performed using a GSS-API-based key exchange method defined in accordance with Section 2.
如果初始密钥交换是使用基于GSS API的密钥交换方法执行的，并且提供了对服务器有用的有关用户身份的信息，则服务器应将此用户身份验证方法包括在可继续（在SSH_MSG_USERAUTH_故障中）的方法列表中。如果初始密钥交换未使用根据第2节定义的基于GSS API的密钥交换方法执行，则不得包括此方法。
The client SHOULD attempt to use this method if it is advertised by the server, initial key exchange was performed using a GSS-API-based key exchange method, and this method has not already been tried. The client SHOULD NOT try this method more than once per session. It MUST NOT try this method if initial key exchange was not performed using a GSS-API-based key exchange method defined in accordance with Section 2.
如果服务器播发此方法，并且使用基于GSS API的密钥交换方法执行初始密钥交换，并且尚未尝试此方法，则客户端应尝试使用此方法。客户端不应在每个会话中多次尝试此方法。如果未使用第2节定义的基于GSS API的密钥交换方法执行初始密钥交换，则不得尝试此方法。
If a server receives a request for this method when initial key exchange was not performed using a GSS-API-based key exchange method defined in accordance with Section 2, it MUST return SSH_MSG_USERAUTH_FAILURE.
如果服务器在未使用根据第2节定义的基于GSS API的密钥交换方法执行初始密钥交换时收到此方法的请求，则必须返回SSH_MSG_USERAUTH_FAILURE。
This method is defined as a single message:
此方法定义为单个消息：
byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-keyex" string MIC
字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务字符串“gssapi keyex”字符串麦克风
The contents of the MIC field are obtained by calling GSS_GetMIC over the following, using the GSS-API context that was established during initial key exchange:
通过使用初始密钥交换期间建立的GSS-API上下文，通过以下方式调用GSS_GetMIC来获取MIC字段的内容：
string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-keyex"
字符串会话标识符字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务字符串“gssapi keyex”
Upon receiving this message when initial key exchange was performed using a GSS-API-based key exchange method, the server uses GSS_VerifyMIC() to verify that the MIC received is valid. If the MIC is not valid, the user authentication fails, and the server MUST return SSH_MSG_USERAUTH_FAILURE.
当使用基于GSS API的密钥交换方法执行初始密钥交换时，服务器收到此消息后，使用GSS_VerifyMIC（）验证接收到的MIC是否有效。如果MIC无效，则用户身份验证失败，服务器必须返回SSH\u MSG\u USERAUTH\u FAILURE。
If the MIC is valid and the server is satisfied as to the user's credentials, it MAY return either SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE with the partial success flag set, depending on whether additional authentications are needed.
如果MIC有效且服务器对用户的凭据感到满意，则它可能会返回SSH_MSG_USERAUTH_SUCCESS或SSH_MSG_USERAUTH_FAILURE，并设置部分成功标志，具体取决于是否需要额外的身份验证。
The "null" host key algorithm has no associated host key material and provides neither signature nor encryption algorithms. Thus, it can be used only with key exchange methods that do not require any public-key operations and do not require the use of host public key material. The key exchange methods described in Section 2 are examples of such methods.
“空”主机密钥算法没有关联的主机密钥材料，并且既不提供签名也不提供加密算法。因此，它只能用于不需要任何公钥操作且不需要使用宿主公钥材料的密钥交换方法。第2节中描述的密钥交换方法是此类方法的示例。
This algorithm is used when, as a matter of configuration, the host does not have or does not wish to use a public key. For example, it can be used when the administrator has decided as a matter of policy to require that all key exchanges be authenticated using Kerberos [KRB5], and thus the only permitted key exchange method is the GSS-API-authenticated Diffie-Hellman exchange described above, with Kerberos V5 as the underlying GSS-API mechanism. In such a configuration, the server implementation supports the "ssh-dss" key algorithm (as required by [SSH-TRANSPORT]), but could be prohibited by configuration from using it. In this situation, the server needs some key exchange algorithm to advertise; the "null" algorithm fills this purpose.
此算法在主机没有或不希望使用公钥时使用（作为配置事项）。例如，当管理员根据策略决定要求使用Kerberos[KRB5]对所有密钥交换进行身份验证时，可以使用该方法，因此唯一允许的密钥交换方法是上述GSS API验证的Diffie-Hellman交换，Kerberos V5作为底层GSS-API机制。在这种配置中，服务器实现支持“ssh-dss”密钥算法（根据[ssh-TRANSPORT]的要求），但可能会被配置禁止使用它。在这种情况下，服务器需要一些密钥交换算法来发布；“空”算法满足了这一目的。
Note that the use of the "null" algorithm in this way means that the server will not be able to interoperate with clients that do not support this algorithm. This is not a significant problem, since in the configuration described, it will also be unable to interoperate with implementations that do not support the GSS-API-authenticated key exchange and Kerberos.
请注意，以这种方式使用“null”算法意味着服务器将无法与不支持此算法的客户端进行互操作。这不是一个重大问题，因为在所描述的配置中，它也将无法与不支持GSS API认证密钥交换和Kerberos的实现进行互操作。
Any implementation supporting at least one key exchange method that conforms to Section 2 MUST also support the "null" host key algorithm. Servers MUST NOT advertise the "null" host key algorithm unless it is the only algorithm advertised.
任何支持至少一种符合第2节的密钥交换方法的实现也必须支持“null”主机密钥算法。服务器不得公布“null”主机密钥算法，除非它是唯一公布的算法。
The following message numbers have been defined for use with GSS-API-based key exchange methods:
已定义以下消息编号，用于基于GSS API的密钥交换方法：
#define SSH_MSG_KEXGSS_INIT 30 #define SSH_MSG_KEXGSS_CONTINUE 31 #define SSH_MSG_KEXGSS_COMPLETE 32 #define SSH_MSG_KEXGSS_HOSTKEY 33 #define SSH_MSG_KEXGSS_ERROR 34 #define SSH_MSG_KEXGSS_GROUPREQ 40 #define SSH_MSG_KEXGSS_GROUP 41
#定义SSH_MSG_KEXGSS_INIT 30#定义SSH_MSG_KEXGSS_CONTINUE 31#定义SSH_MSG_KEXGSS_COMPLETE 32#定义SSH_MSG_KEXGSS_主机密钥33#定义SSH_MSG_KEXGSS_错误34#定义SSH_MSG_KEXGSS_GROUPREQ 40#定义SSH_MSG_kegss_kegss#组41
The numbers 30-49 are specific to key exchange and may be redefined by other kex methods.
数字30-49特定于密钥交换，可以通过其他kex方法重新定义。
The following message numbers have been defined for use with the 'gssapi-with-mic' user authentication method:
以下消息编号已定义为与“gssapi with mic”用户身份验证方法一起使用：
#define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60 #define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61 #define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63 #define SSH_MSG_USERAUTH_GSSAPI_ERROR 64 #define SSH_MSG_USERAUTH_GSSAPI_ERRTOK 65 #define SSH_MSG_USERAUTH_GSSAPI_MIC 66
#定义SSH_MSG_USERAUTH_GSSAPI_响应60#定义SSH_MSG_USERAUTH_GSSAPI_令牌61#定义SSH_MSG_USERAUTH_GSSAPI_交换63#定义SSH_MSG_USERAUTH_GSSAPI_错误64#定义SSH_MSG_USERAUTH_GSSAPI_ERRTOK 65#定义SSH
The numbers 60-79 are specific to user authentication and may be redefined by other user auth methods. Note that in the method described in this document, message number 62 is unused.
数字60-79特定于用户身份验证，可由其他用户身份验证方法重新定义。注意，在本文档中描述的方法中，未使用消息编号62。
In order to establish a GSS-API security context, the SSH client needs to determine the appropriate targ_name to use in identifying the server when calling GSS_Init_sec_context(). For this purpose, the GSS-API mechanism-independent name form for host-based services is used, as described in Section 4.1 of [GSSAPI].
为了建立GSS-API安全上下文，SSH客户端需要确定在调用GSS_Init_sec_context（）时用于标识服务器的适当目标名称。为此，如[GSSAPI]第4.1节所述，使用基于主机的服务的GSS-API机制独立名称形式。
In particular, the targ_name to pass to GSS_Init_sec_context() is obtained by calling GSS_Import_name() with an input_name_type of GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of the string "host@" concatenated with the hostname of the SSH server.
特别是，要传递给GSS_Init_sec_context（）的目标名称是通过使用GSS_C_NT_HOSTBASED_服务的输入名称类型调用GSS_Import_name（）和由字符串“host@”与SSH服务器主机名连接而成的输入名称字符串来获得的。
Because the GSS-API mechanism uses the targ_name to authenticate the server's identity, it is important that it be determined in a secure fashion. One common way to do this is to construct the targ_name from the hostname as typed by the user; unfortunately, because some GSS-API mechanisms do not canonicalize hostnames, it is likely that this technique will fail if the user has not typed a fully-qualified, canonical hostname. Thus, implementers may wish to use other methods, but should take care to ensure they are secure. For example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, or an IP address to a hostname, since an attacker can modify the mapping and impersonate the server.
由于GSS-API机制使用targ_名称来验证服务器的身份，因此必须以安全的方式确定它。一种常见的方法是根据用户键入的主机名构造target_名称；不幸的是，由于某些GSS-API机制没有规范化主机名，如果用户没有键入完全限定的规范化主机名，这种技术很可能会失败。因此，实现者可能希望使用其他方法，但应注意确保它们是安全的。例如，不应依赖未受保护的DNS记录将主机别名映射到服务器的主名称，或将IP地址映射到主机名，因为攻击者可以修改映射并模拟服务器。
Implementations of mechanisms conforming to this document MUST NOT use the results of insecure DNS queries to construct the targ_name. Clients MAY make use of a mapping provided by local configuration or use other secure means to determine the targ_name to be used. If a client system is unable to securely determine which targ_name to use, then it SHOULD NOT use this mechanism.
符合本文档要求的机制的实现不得使用不安全DNS查询的结果来构造目标名称。客户端可以使用本地配置提供的映射，或者使用其他安全方法来确定要使用的目标名称。如果客户端系统无法安全地确定要使用的目标名称，则不应使用此机制。
This document recommends that channel bindings SHOULD NOT be specified in the calls during context establishment. This document does not specify any standard data to be used as channel bindings, and the use of network addresses as channel bindings may break SSH in environments where it is most useful.
本文档建议在建立上下文期间，不应在调用中指定通道绑定。本文档未指定用作通道绑定的任何标准数据，在SSH最有用的环境中，使用网络地址作为通道绑定可能会破坏SSH。
The use of the Simple and Protected GSS-API Negotiation Mechanism [SPNEGO] in conjunction with the authentication and key exchange methods described in this document is both unnecessary and undesirable. As a result, mechanisms conforming to this document MUST NOT use SPNEGO as the underlying GSS-API mechanism.
将简单且受保护的GSS-API协商机制[SPNEGO]与本文档中描述的身份验证和密钥交换方法结合使用既不必要也不可取。因此，符合本文件要求的机制不得将SPNEGO用作基础GSS-API机制。
Since SSH performs its own negotiation of authentication and key exchange methods, the negotiation capability of SPNEGO alone does not provide any added benefit. In fact, as described below, it has the potential to result in the use of a weaker method than desired.
由于SSH自己执行身份验证和密钥交换方法的协商，因此SPNEGO的协商功能本身并不能提供任何额外的好处。事实上，如下文所述，它有可能导致使用比预期更弱的方法。
Normally, SPNEGO provides the added benefit of protecting the GSS-API mechanism negotiation. It does this by having the server compute a MIC of the list of mechanisms proposed by the client, and then checking that value at the client. In the case of key exchange, this protection is not needed because the key exchange methods described here already perform an equivalent operation; namely, they generate a MIC of the SSH exchange hash, which is a hash of several items including the lists of key exchange mechanisms supported by both sides. In the case of user authentication, the protection is not needed because the negotiation occurs over a secure channel, and the host's identity has already been proved to the user.
通常，SPNEGO提供了保护GSS-API协商机制的额外好处。它是通过让服务器计算客户机建议的机制列表的MIC，然后在客户机上检查该值来实现的。在密钥交换的情况下，不需要这种保护，因为这里描述的密钥交换方法已经执行了等效的操作；也就是说，它们生成SSH交换散列的MIC，这是几个项目的散列，包括双方支持的密钥交换机制列表。在用户身份验证的情况下，不需要保护，因为协商发生在安全通道上，并且主机的身份已经向用户证明。
The use of SPNEGO combined with GSS-API mechanisms used without SPNEGO can lead to interoperability problems. For example, a client that supports key exchange using the Kerberos V5 GSS-API mechanism [KRB5-GSS] only underneath SPNEGO will not interoperate with a server that supports key exchange only using the Kerberos V5 GSS-API mechanism directly. As a result, allowing GSS-API mechanisms to be used both with and without SPNEGO is undesirable.
将SPNEGO与未使用SPNEGO的GSS-API机制结合使用可能会导致互操作性问题。例如，仅在SPNEGO下使用Kerberos V5 GSS-API机制[KRB5-GSS]支持密钥交换的客户端将不会直接与仅使用Kerberos V5 GSS-API机制支持密钥交换的服务器进行互操作。因此，允许GSS-API机制同时使用SPNEGO和不使用SPNEGO都是不可取的。
If a client's policy is to first prefer GSS-API-based key exchange method X, then non-GSS-API method Y, then GSS-API-based method Z, and if a server supports mechanisms Y and Z but not X, then an attempt to use SPNEGO to negotiate a GSS-API mechanism might result in the use of method Z when method Y would have been preferable. As a result, the use of SPNEGO could result in the subversion of the negotiation algorithm for key exchange methods as described in Section 7.1 of [SSH-TRANSPORT] and/or the negotiation algorithm for user authentication methods as described in [SSH-USERAUTH].
如果客户机的策略是首先选择基于GSS API的密钥交换方法X，然后是非GSS API方法Y，然后是基于GSS API的方法Z，并且如果服务器支持机制Y和Z，但不支持X，则尝试使用SPNEGO协商GSS-API机制可能会导致在方法Y更可取时使用方法Z。因此，使用SPNEGO可能会破坏[SSH-TRANSPORT]第7.1节所述的密钥交换方法协商算法和/或[SSH-USERAUTH]所述的用户身份验证方法协商算法。
Consistent with Section 8 of [SSH-ARCH] and Section 4.6 of [SSH-NUMBERS], this document makes the following registrations:
根据[SSH-ARCH]的第8节和[SSH-NUMBERS]的第4.6节，本文件进行了以下注册：
The family of SSH key exchange method names beginning with "gss-group1-sha1-" and not containing the at-sign ('@'), to name the key exchange methods defined in Section 2.3.
SSH密钥交换方法系列名称以“gss-group1-sha1-”开头，不包含at符号（“@”），用于命名第2.3节中定义的密钥交换方法。
The family of SSH key exchange method names beginning with "gss-gex-sha1-" and not containing the at-sign ('@'), to name the key exchange methods defined in Section 2.5.
SSH密钥交换方法系列名称以“gss-gex-sha1-”开头，不包含at符号（“@”），用于命名第2.5节中定义的密钥交换方法。
All other SSH key exchange method names beginning with "gss-" and not containing the at-sign ('@'), to be reserved for future key exchange methods defined in conformance with this document, as noted in Section 2.6.
如第2.6节所述，以“gss-”开头且不包含at符号（“@”）的所有其他SSH密钥交换方法名称将保留给根据本文档定义的未来密钥交换方法。
The SSH host public key algorithm name "null", to name the NULL host key algorithm defined in Section 5.
SSH主机公钥算法名称为“null”，用于命名第5节中定义的null主机密钥算法。
The SSH user authentication method name "gssapi-with-mic", to name the GSS-API user authentication method defined in Section 3.
SSH用户身份验证方法名为“gssapi with mic”，以命名第3节中定义的GSS-API用户身份验证方法。
The SSH user authentication method name "gssapi-keyex", to name the GSS-API user authentication method defined in Section 4.
SSH用户身份验证方法名为“gssapi keyex”，用于命名第4节中定义的GSS-API用户身份验证方法。
The SSH user authentication method name "gssapi" is to be reserved, in order to avoid conflicts with implementations supporting an earlier version of this specification.
保留SSH用户身份验证方法名称“gssapi”，以避免与支持本规范早期版本的实现发生冲突。
The SSH user authentication method name "external-keyx" is to be reserved, in order to avoid conflicts with implementations supporting an earlier version of this specification.
保留SSH用户身份验证方法名称“external keyx”，以避免与支持本规范早期版本的实现发生冲突。
This document creates no new registries.
此文档不创建新的注册表。
This document describes authentication and key-exchange protocols. As such, security considerations are discussed throughout.
本文档描述了身份验证和密钥交换协议。因此，始终讨论安全性考虑。
This protocol depends on the SSH protocol itself, the GSS-API, any underlying GSS-API mechanisms that are used, and any protocols on which such mechanisms might depend. Each of these components plays a part in the security of the resulting connection, and each will have its own security considerations.
此协议取决于SSH协议本身、GSS-API、所使用的任何底层GSS-API机制以及这些机制可能依赖的任何协议。这些组件中的每一个都在生成的连接的安全性中发挥作用，并且每个组件都有自己的安全考虑因素。
The key exchange method described in Section 2 depends on the underlying GSS-API mechanism to provide both mutual authentication and per-message integrity services. If either of these features is not supported by a particular GSS-API mechanism, or by a particular implementation of a GSS-API mechanism, then the key exchange is not secure and MUST fail.
第2节中描述的密钥交换方法依赖于底层GSS-API机制来提供相互身份验证和每消息完整性服务。如果特定GSS-API机制或GSS-API机制的特定实现不支持这些功能，则密钥交换不安全，必须失败。
In order for the "external-keyx" user authentication method to be used, it MUST have access to user authentication information obtained as a side-effect of the key exchange. If this information is unavailable, the authentication MUST fail.
为了使用“external keyx”用户身份验证方法，它必须能够访问作为密钥交换的副作用而获得的用户身份验证信息。如果此信息不可用，则身份验证必须失败。
Revealing information about the reason for an authentication failure may be considered by some sites to be an unacceptable security risk for a production environment. However, having that information available can be invaluable for debugging purposes. Thus, it is RECOMMENDED that implementations provide a means for controlling, as a matter of policy, whether to send SSH_MSG_USERAUTH_GSSAPI_ERROR, SSH_MSG_USERAUTH_GSSAPI_ERRTOK, and SSH_MSG_KEXGSS_ERROR messages, and SSH_MSG_KEXGSS_CONTINUE messages containing a GSS-API error token.
某些站点可能会认为，透露身份验证失败原因的信息对于生产环境来说是不可接受的安全风险。然而，拥有用于调试的信息是非常宝贵的。因此，建议实现提供一种方法，作为一种策略，用于控制是否发送SSH_MSG_USERAUTH_GSSAPI_ERROR、SSH_MSG_USERAUTH_GSSAPI_ERRTOK和SSH_MSG_KEXGSS_错误消息，以及包含GSS-API错误令牌的SSH_MSG_KEXGSS_CONTINUE消息。
The authors would like to thank the following individuals for their invaluable assistance and contributions to this document:
作者要感谢以下个人对本文件的宝贵帮助和贡献：
o Sam Hartman
o 萨姆·哈特曼
o Love Hornquist-Astrand
o 爱霍恩奎斯特阿斯特兰
o Joel N. Weber II
o 韦伯二世
o Simon Wilkinson
o 西蒙·威尔金森
o Nicolas Williams
o 尼古拉斯·威廉姆斯
Much of the text describing DH group exchange was borrowed from [GROUP-EXCHANGE], by Markus Friedl, Niels Provos, and William A. Simpson.
描述DH group exchange的大部分文本都是从[group-exchange]借用的，作者是Markus Friedl、Niels Provos和William A.Simpson。
[ASN1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690 (1997), ISO/ IEC 8825-1:1998, November 1998.
[ASN1]ISO/IEC，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690（1997），ISO/IEC 8825-1:1998，1998年11月。
[GROUP-EXCHANGE] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, March 2006.
[GROUP-EXCHANGE]Friedl，M.，Provos，N.，和W.Simpson，“用于安全外壳（SSH）传输层协议的Diffie-Hellman组交换”，RFC 4419，2006年3月。
[GSSAPI] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSSAPI]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LANGTAG] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANGTAG]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[SSH-ARCH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[SSH-CONNECT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-CONNECT]Ylonen，T.和C.Lonvick，“安全外壳（SSH）连接协议”，RFC 4254，2006年1月。
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS]Lehtinen，S.和C.Lonvick，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[SSH-TRANSPORT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANSPORT]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH]Ylonen，T.和C.Lonvick，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[KRB5] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KRB5]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[KRB5-GSS] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[KRB5-GSS]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPREP]Zeilenga，K.，“SASLPREP:Stringprep用户名和密码配置文件”，RFC 4013，2005年2月。
[SPNEGO] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.
[SPNEGO]Zhu，L.，Leach，P.，Jaganathan，K.，和W.Ingersoll，“简单和受保护的通用安全服务应用程序接口（GSS-API）协商机制”，RFC 4178，2005年10月。
Authors' Addresses
作者地址
Jeffrey Hutzelman Carnegie Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 US
美国宾夕法尼亚州匹兹堡福布斯大道5000号杰弗里·哈泽尔曼卡内基梅隆大学15213
Phone: +1 412 268 7225
EMail: jhutz+@cmu.edu
URI: http://www.cs.cmu.edu/~jhutz/
Phone: +1 412 268 7225
EMail: jhutz+@cmu.edu
URI: http://www.cs.cmu.edu/~jhutz/
Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
Joseph Galbraith Van Dyke Technologies, Inc. 4848 Tramway Ridge Dr. NE Suite 101 Albuquerque, NM 87111 US
Joseph Galbraith Van Dyke Technologies，Inc.4848美国新墨西哥州阿尔伯克基市电车桥东北101号套房，邮编87111
EMail: galb@vandyke.com
EMail: galb@vandyke.com
Von Welch University of Chicago & Argonne National Laboratory Distributed Systems Laboratory 701 E. Washington Urbana, IL 61801 US
Von韦尔奇芝加哥大学和阿贡国家实验室分布式系统实验室701 E.华盛顿厄尔巴纳，IL 61801美国
EMail: welch@mcs.anl.gov
EMail: welch@mcs.anl.gov
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）提供。