Network Working Group F. Cusack
Request for Comments: 4256 savecore.net
Category: Standards Track M. Forssen
AppGate Network Security AB
January 2006
Network Working Group F. Cusack
Request for Comments: 4256 savecore.net
Category: Standards Track M. Forssen
AppGate Network Security AB
January 2006
Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
安全外壳协议（SSH）的通用消息交换身份验证
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s).
安全外壳协议（SSH）是一种用于在不安全的网络上进行安全远程登录和其他安全网络服务的协议。本文档描述了SSH协议的通用身份验证方法，适用于交互式身份验证，其中身份验证数据应通过键盘（或等效的字母数字输入设备）输入。此方法的主要目标是允许SSH客户端支持整个类别的身份验证机制，而不知道实际身份验证机制的细节。
The SSH authentication protocol [SSH-USERAUTH] is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection.
SSH身份验证协议[SSH-USERAUTH]是一种通用用户身份验证协议。它打算在SSH传输层协议[SSH-TRANS]上运行。身份验证协议假定基础协议提供完整性和机密性保护。
This document describes a general purpose authentication method for the SSH authentication protocol. This method is suitable for interactive authentication methods that do not need any special software support on the client side. Instead, all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of
本文档描述了SSH身份验证协议的通用身份验证方法。此方法适用于客户端不需要任何特殊软件支持的交互式身份验证方法。相反，应通过键盘输入所有身份验证数据。此方法的主要目标是允许SSH客户端对
the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code.
SSH服务器使用的底层身份验证机制的详细信息。这将允许服务器任意选择或更改底层身份验证机制，而无需更新客户端代码。
The name for this authentication method is "keyboard-interactive".
此身份验证方法的名称为“键盘交互”。
This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation.
只有在阅读了SSH体系结构文档[SSH-ARCH]和SSH身份验证文档[SSH-USERAUTH]之后，才能阅读此文档。本文件免费使用两份文件中的术语和符号，无需参考或进一步解释。
This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is described here anyway because some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations.
本文档还描述了在获取身份验证信息时客户端与用户的一些交互。虽然这在某种程度上超出了协议规范的范围，但这里还是对其进行了描述，因为协议的某些方面是根据用户界面问题专门设计的，省略这些信息可能会导致不兼容或笨拙的实现。
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 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. This makes it difficult to add new mechanisms for authentication as all clients must be updated to support the new mechanism. With the generic method defined here, clients will not require code changes to support new authentication mechanisms, and if a separate authentication layer is used, such as [PAM], then the server may not need any code changes either.
当前定义的SSH身份验证方法与底层身份验证机制紧密耦合。这使得添加新的身份验证机制变得困难，因为必须更新所有客户端以支持新机制。使用此处定义的通用方法，客户端将不需要更改代码以支持新的身份验证机制，并且如果使用单独的身份验证层，如[PAM]，则服务器也可能不需要更改任何代码。
This presents a significant advantage to other methods, such as the "password" method (defined in [SSH-USERAUTH]), as new (presumably stronger) methods may be added "at will" and system security can be transparently enhanced.
这与其他方法（如“密码”方法（在[SSH-USERAUTH]中定义））相比具有显著优势，因为可以“随意”添加新的（可能更强的）方法，并且可以透明地增强系统安全性。
Challenge-response and One Time Password mechanisms are also easily supported with this authentication method.
这种身份验证方法也很容易支持质询响应和一次性密码机制。
However, this authentication method is limited to authentication mechanisms that do not require any special code, such as hardware drivers or password mangling, on the client.
但是，此身份验证方法仅限于在客户端上不需要任何特殊代码（如硬件驱动程序或密码篡改）的身份验证机制。
The client initiates the authentication with an SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with an SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with an SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client.
客户端使用SSH_MSG_USERAUTH_请求消息启动身份验证。然后，服务器使用SSH\u MSG\u USERAUTH\u INFO\u请求消息从客户端请求身份验证信息。客户端从用户处获取信息，然后使用SSM\u MSG\u USERAUTH\u INFO\u响应消息进行响应。在从客户端收到答复之前，服务器不得发送另一个SSH_MSG_USERAUTH_INFO_请求。
The authentication starts with the client sending the following packet:
身份验证从客户端发送以下数据包开始：
byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8)
字节SSH_MSG_USERAUTH_请求字符串用户名（ISO-10646 UTF-8，定义见[RFC-3629]）字符串服务名称（US-ASCII）字符串“键盘交互”（US-ASCII）字符串语言标记（定义见[RFC-3066]）字符串子方法（ISO-10646 UTF-8）
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language to be used based on the tags communicated during key exchange [SSH-TRANS].
语言标记已弃用，应为空字符串。在本规范的未来版本中，可将其删除。相反，服务器应该根据密钥交换[SSH-TRANS]期间传递的标记选择要使用的语言。
If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
如果language标记不是空字符串，则服务器应将指定的语言用于作为此协议一部分发送到客户端的任何消息。语言标记不应用于此协议之外的消息的语言选择。如果服务器不支持请求的语言，则使用的语言取决于实现。
The submethods field is included so the user can give a hint of which actual methods he wants to use. It is a comma-separated list of authentication submethods (software or hardware) that the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise, it MUST send the empty string.
submethods字段包含在内，因此用户可以给出他想要使用的实际方法的提示。它是一个逗号分隔的用户首选的身份验证子方法（软件或硬件）列表。如果客户机知道用户首选的子方法（可能是通过配置设置），它可以使用子方法字段将此信息传递给服务器。否则，它必须发送空字符串。
The actual names of the submethods is something the user and the server need to agree upon.
子方法的实际名称需要用户和服务器达成一致。
Server interpretation of the submethods field is implementation-dependent.
submethods字段的服务器解释取决于实现。
One possible implementation strategy of the submethods field on the server is that, unless the user may use multiple different submethods, the server ignores this field. If the user may authenticate using one of several different submethods, the server should treat the submethods field as a hint on which submethod the user wants to use this time.
服务器上submethods字段的一种可能实现策略是，除非用户可以使用多个不同的submethods，否则服务器将忽略此字段。如果用户可以使用几种不同的子方法中的一种进行身份验证，则服务器应将submethods字段视为用户这次要使用的子方法的提示。
Note that when this message is sent to the server, the client has not yet prompted the user for a password, and so that information is NOT included with this initial message (unlike the "password" method).
请注意，当此消息发送到服务器时，客户端尚未提示用户输入密码，因此此初始消息中不包含信息（与“密码”方法不同）。
The server MUST reply with an SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
服务器必须使用SSH\u MSG\u USERAUTH\u成功、SSH\u MSG\u USERAUTH\u失败或SSH\u MSG\u USERAUTH\u信息请求消息进行回复。
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead, it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s), which look just like the one(s) that would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid usernames by comparing the results when authenticating as different users.
如果失败基于用户名或服务名，则服务器不应回复SSH_MSG_USERAUTH_失败消息；相反，它应该发送SSH_MSG_USERAUTH_INFO_请求消息，这些消息看起来就像在应该继续进行身份验证的情况下发送的消息，然后发送失败消息（经过适当的延迟，如下所述）。其目标是，当作为不同的用户进行身份验证时，通过比较结果，不可能找到有效的用户名。
The server MAY reply with an SSH_MSG_USERAUTH_SUCCESS message if no authentication is required for the user in question. However, a better approach, for reasons discussed above, might be to reply with an SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate) the response.
如果不需要对相关用户进行身份验证，服务器可能会回复SSH_MSG_USERAUTH_SUCCESS消息。但是，出于上面讨论的原因，更好的方法可能是使用SSH\u MSG\u USERAUTH\u INFO\u请求消息进行回复，并忽略（不验证）响应。
Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message.
使用SSH\u MSG\u USERAUTH\u INFO\u请求消息从服务器生成请求。
The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However, the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may not send another request before the client has answered.
服务器可以发送验证客户端所需的任意数量的请求；客户必须准备好处理多次交易。但是，服务器不能有超过一个SSH\u MSG\u USERAUTH\u INFO\u请求消息未完成。也就是说，在客户端应答之前，它可能不会发送另一个请求。
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
SSH\u MSG\u USERAUTH\u INFO\u请求消息定义如下：
byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts]
字节SSH\u MSG\u USERAUTH\u INFO\u请求字符串名称（ISO-10646 UTF-8）字符串指令（ISO-10646 UTF-8）字符串语言标记（如[RFC-3066]中所定义）int num提示字符串提示[1]（ISO-10646 UTF-8）布尔回显[1]。。。字符串提示[num提示]（ISO-10646 UTF-8）布尔回显[num提示]
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language used based on the tags communicated during key exchange [SSH-TRANS].
语言标记已弃用，应为空字符串。在本规范的未来版本中，可将其删除。相反，服务器应该根据密钥交换[SSH-TRANS]期间通信的标记选择使用的语言。
If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
如果language标记不是空字符串，则服务器应将指定的语言用于作为此协议一部分发送到客户端的任何消息。语言标记不应用于此协议之外的消息的语言选择。如果服务器不支持请求的语言，则使用的语言取决于实现。
The server SHOULD take into consideration that some clients may not be able to properly display a long name or prompt field (see next section), and limit the lengths of those fields if possible. For example, instead of an instruction field of "Enter Password" and a prompt field of "Password for user23@host.domain: ", a better choice might be an instruction field of "Password authentication for user23@host.domain" and a prompt field of "Password: ". It is expected that this authentication method would typically be backended by [PAM] and so such choices would not be possible.
服务器应考虑到某些客户端可能无法正确显示长名称或提示字段（请参阅下一节），并尽可能限制这些字段的长度。例如，不是“输入密码”的指令字段，而是“输入密码”的提示字段user23@host.domain：，更好的选择可能是“密码身份验证”的指令字段user23@host.domain以及提示字段“密码：”。预计此身份验证方法通常会被[PAM]回退，因此不可能进行此类选择。
The name and instruction fields MAY be empty strings; the client MUST be prepared to handle this correctly. The prompt field(s) MUST NOT be empty strings.
名称和指令字段可以是空字符串；客户必须准备好正确处理此问题。提示字段不能为空字符串。
The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below).
num prompts字段可能为“0”，在这种情况下，消息中不会有提示/回显字段，但客户端仍应显示名称和说明字段（如下所述）。
Upon receiving a request message, the client SHOULD prompt the user as follows:
收到请求消息后，客户端应按如下方式提示用户：
A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then, for each prompt in turn, the client SHOULD display the prompt and read the user input.
命令行界面（CLI）客户端应打印名称和指令（如果非空），并添加换行符。然后，对于依次出现的每个提示，客户端应显示提示并读取用户输入。
A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user. For example, an implementation SHOULD NOT discard the name field because its windows lack titles; instead, it SHOULD find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window.
图形用户界面（GUI）客户端在如何提示用户方面有许多选择。一种可能是使用名称字段（可能以应用程序名称为前缀）作为显示提示的对话框窗口的标题。在该对话框窗口中，指令字段将是文本消息，提示将是文本输入字段的标签。所有字段都应显示给用户。例如，一个实现不应该因为它的窗口缺少标题而放弃名称字段；相反，它应该找到另一种方式来显示这些信息。如果在对话框窗口中显示提示，则客户端不应在单独的窗口中显示每个提示。
All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occurred. The instruction field SHOULD NOT be truncated.
所有客户端都必须正确处理带有嵌入换行符的指令字段。他们还应该能够显示至少30个字符的名称和提示。如果服务器显示的名称或提示长度超过30个字符，则客户端可能会将这些字段截断为其可以显示的长度。如果客户端确实截断了任何字段，则必须有一个明显的指示，表明已发生此类截断。指令字段不应被截断。
Clients SHOULD use control character filtering, as discussed in [SSH-ARCH], to avoid attacks by including terminal control characters in the fields to be displayed.
客户端应该使用控制字符过滤，如[SSH-ARCH]中所述，通过在要显示的字段中包含终端控制字符来避免攻击。
For each prompt, the corresponding echo field indicates whether the
user input should be echoed as characters are typed. Clients SHOULD
correctly echo/mask user input for each prompt independently of other
prompts in the request message. If a client does not honor the echo
field for whatever reason, then the client MUST err on the side of
masking input. A GUI client might like to have a checkbox toggling
echo/mask. Clients SHOULD NOT add any additional characters to the
prompt, such as ": " (colon-space); the server is responsible for
supplying all text to be displayed to the user. Clients MUST also
accept empty responses from the user and pass them on as empty
strings.
For each prompt, the corresponding echo field indicates whether the
user input should be echoed as characters are typed. Clients SHOULD
correctly echo/mask user input for each prompt independently of other
prompts in the request message. If a client does not honor the echo
field for whatever reason, then the client MUST err on the side of
masking input. A GUI client might like to have a checkbox toggling
echo/mask. Clients SHOULD NOT add any additional characters to the
prompt, such as ": " (colon-space); the server is responsible for
supplying all text to be displayed to the user. Clients MUST also
accept empty responses from the user and pass them on as empty
strings.
After obtaining the requested information from the user, the client MUST respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message.
从用户处获取请求的信息后，客户端必须使用SSH\u MSG\u USERAUTH\u INFO\u响应消息进行响应。
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows:
SSH_MSG_USERAUTH_INFO_响应消息的格式如下：
byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8)
字节SSH\u MSG\u USERAUTH\u INFO\u RESPONSE int num responses string RESPONSE[1]（ISO-10646 UTF-8）。。。字符串响应[num响应]（ISO-10646 UTF-8）
Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting.
请注意，响应以ISO-10646 UTF-8编码。这取决于服务器如何解释和验证响应。但是，如果客户端以其他编码（例如ISO 8859-1）读取响应，则必须在传输之前将响应转换为ISO-10646 UTF-8。
From an internationalization standpoint, it is desired that if a user enters responses, the authentication process will work regardless of what OS and client software they are using. Doing so requires normalization. Systems supporting non-ASCII passwords SHOULD always normalize passwords and usernames whenever they are added to the database, or compare them (with or without hashing) to existing entries in the database. SSH implementations that both store the passwords and compare them SHOULD use [SASLPREP] for normalization.
从国际化的角度来看，如果用户输入响应，则无论他们使用的是什么操作系统和客户端软件，身份验证过程都将正常工作。这样做需要标准化。支持非ASCII密码的系统在将密码和用户名添加到数据库时，应始终对其进行规范化，或将其与数据库中的现有条目进行比较（有无哈希）。存储并比较密码的SSH实现应该使用[SASLPREP]进行规范化。
If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message.
如果num responses字段与请求消息中的num prompts字段不匹配，则服务器必须发送失败消息。
In the case that the server sends a `0' num-prompts field in the request message, the client MUST send a response message with a `0' num-responses field to complete the exchange.
如果服务器在请求消息中发送'0'num prompts字段，则客户端必须发送带有'0'num responses字段的响应消息以完成交换。
The responses MUST be ordered as the prompts were ordered. That is, response[n] MUST be the answer to prompt[n].
响应的顺序必须与提示的顺序相同。也就是说，响应[n]必须是提示[n]的答案。
After receiving the response, the server MUST send either an SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message.
收到响应后，服务器必须发送SSH\u MSG\u USERAUTH\u成功、SSH\u MSG\u USERAUTH\u失败或另一条SSH\u MSG\u USERAUTH\u信息请求消息。
If the server fails to authenticate the user (through the underlying authentication mechanism(s)), it SHOULD NOT send another request message(s) in an attempt to obtain new authentication data; instead, it SHOULD send a failure message. The only time the server should send multiple request messages is if additional authentication data
如果服务器未能（通过底层身份验证机制）对用户进行身份验证，则不应发送另一条请求消息以尝试获取新的身份验证数据；相反，它应该发送一条失败消息。服务器应该发送多个请求消息的唯一时间是如果有其他身份验证数据
is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user).
需要（即，因为必须使用多个底层身份验证机制来验证用户）。
If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending it to the client. It is suspected that implementations are likely to make the time delay configurable; a suggested default is 2 seconds.
如果服务器打算以失败消息进行响应，则在将其发送到客户端之前，它可能会延迟一段与实现相关的时间。怀疑实现可能会使时间延迟可配置；建议的默认值为2秒。
Here are two example exchanges between a client and server. The first is an example of challenge/response with a handheld token. This is an authentication that is not otherwise possible with other authentication methods.
下面是客户机和服务器之间的两个示例交换。第一个是手持令牌的质询/响应示例。这是其他身份验证方法无法实现的身份验证。
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string ""
C: string ""
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string ""
C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "CRYPTOCard Authentication"
S: string "The challenge is '14315716'"
S: string "en-US"
S: int 1
S: string "Response: "
S: boolean TRUE
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "CRYPTOCard Authentication"
S: string "The challenge is '14315716'"
S: string "en-US"
S: int 1
S: string "Response: "
S: boolean TRUE
[Client prompts user for password]
[客户端提示用户输入密码]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "6d757575"
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "6d757575"
S: byte SSH_MSG_USERAUTH_SUCCESS
S:byte SSH\u MSG\u USERAUTH\u成功
The second example is a standard password authentication; in this case, the user's password is expired.
第二个示例是标准密码验证；在这种情况下，用户的密码已过期。
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string "en-US"
C: string ""
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string "en-US"
C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication"
S: string ""
S: string "en-US"
S: int 1
S: string "Password: "
S: boolean FALSE
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication"
S: string ""
S: string "en-US"
S: int 1
S: string "Password: "
S: boolean FALSE
[Client prompts user for password]
[客户端提示用户输入密码]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "password"
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "password"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired."
S: string "en-US"
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired."
S: string "en-US"
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
[Client prompts user for new password]
[客户端提示用户输入新密码]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 2
C: string "newpass"
C: string "newpass"
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 2
C: string "newpass"
C: string "newpass"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password changed"
S: string "Password successfully changed for user23."
S: string "en-US"
S: int 0
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password changed"
S: string "Password successfully changed for user23."
S: string "en-US"
S: int 0
[Client displays message to user]
[客户端向用户显示消息]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0
S: byte SSH_MSG_USERAUTH_SUCCESS
S:byte SSH\u MSG\u USERAUTH\u成功
The userauth type "keyboard-interactive" is used for this authentication method.
userauth类型“keyboard interactive”用于此身份验证方法。
The following method-specific constants are used with this authentication method:
此身份验证方法使用以下特定于方法的常量：
SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61
SSH\u MSG\u USERAUTH\u INFO\u请求60 SSH\u MSG\u USERAUTH\u INFO\u响应61
The authentication protocol and this authentication method depend on the security of the underlying SSH transport layer. Without the confidentiality provided therein, any authentication data passed with this method is subject to interception.
身份验证协议和此身份验证方法取决于底层SSH传输层的安全性。在没有提供保密性的情况下，使用此方法传递的任何身份验证数据都会被拦截。
The number of client-server exchanges required to complete an authentication using this method may be variable. It is possible that an observer may gain valuable information simply by counting that number. For example, an observer may guess that a user's password has expired, and with further observation may be able to determine the password lifetime imposed by a site's password expiration policy.
使用此方法完成身份验证所需的客户端-服务器交换数量可能是可变的。一个观察者可能仅仅通过计算这个数字就能获得有价值的信息。例如，观察者可能会猜测用户的密码已过期，通过进一步观察，可以确定站点密码过期策略所施加的密码生存期。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC-3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC-3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANS]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPREP]Zeilenga，K.，“SASLPREP:Stringprep用户名和密码配置文件”，RFC 4013，2005年2月。
[PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995.
[PAM]Samar，V.，Schemers，R.，“使用可插拔身份验证模块（PAM）的统一登录”，OSF RFC 86.0，1995年10月。
Authors' Addresses
作者地址
Frank Cusack savecore.net
Frank Cusack savecore.net
EMail: frank@savecore.net
EMail: frank@savecore.net
Martin Forssen AppGate Network Security AB Otterhallegatan 2 SE-411 18 Gothenburg SWEDEN
Martin Forssen AppGate网络安全AB Otterhalegatan 2 SE-411 18瑞典哥德堡
EMail: maf@appgate.com
EMail: maf@appgate.com
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）提供。