Network Working Group T. Ylonen
Request for Comments: 4252 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
Network Working Group T. Ylonen
Request for Comments: 4252 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Authentication Protocol
安全Shell（SSH）身份验证协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol.
安全外壳协议（SSH）是一种用于在不安全的网络上进行安全远程登录和其他安全网络服务的协议。本文档介绍SSH身份验证协议框架以及公钥、密码和基于主机的客户端身份验证方法。其他身份验证方法在单独的文档中描述。SSH身份验证协议运行在SSH传输层协议之上，并为SSH连接协议提供一个经过身份验证的隧道。
Table of Contents
目录
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
4. The Authentication Protocol Framework ...........................4
5. Authentication Requests .........................................4
5.1. Responses to Authentication Requests .......................5
5.2. The "none" Authentication Request ..........................7
5.3. Completion of User Authentication ..........................7
5.4. Banner Message .............................................7
6. Authentication Protocol Message Numbers .........................8
7. Public Key Authentication Method: "publickey" ...................8
8. Password Authentication Method: "password" .....................10
9. Host-Based Authentication: "hostbased" .........................12
10. IANA Considerations ...........................................14
11. Security Considerations .......................................14
12. References ....................................................15
12.1. Normative References .....................................15
12.2. Informative References ...................................15
Authors' Addresses ................................................16
Trademark Notice ..................................................16
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
4. The Authentication Protocol Framework ...........................4
5. Authentication Requests .........................................4
5.1. Responses to Authentication Requests .......................5
5.2. The "none" Authentication Request ..........................7
5.3. Completion of User Authentication ..........................7
5.4. Banner Message .............................................7
6. Authentication Protocol Message Numbers .........................8
7. Public Key Authentication Method: "publickey" ...................8
8. Password Authentication Method: "password" .....................10
9. Host-Based Authentication: "hostbased" .........................12
10. IANA Considerations ...........................................14
11. Security Considerations .......................................14
12. References ....................................................15
12.1. Normative References .....................................15
12.2. Informative References ...................................15
Authors' Addresses ................................................16
Trademark Notice ..................................................16
The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. This protocol assumes that the underlying protocols provide integrity and confidentiality protection.
SSH身份验证协议是一种通用用户身份验证协议。它打算在SSH传输层协议[SSH-TRANS]上运行。该协议假定基础协议提供完整性和机密性保护。
This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
只有在阅读了SSH体系结构文档[SSH-ARCH]之后，才能阅读此文档。本文档免费使用架构（architecture）文档中的术语和符号，无需参考或进一步解释。
The 'service name' for this protocol is "ssh-userauth".
此协议的“服务名称”是“ssh userauth”。
When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower-level protocol provides confidentiality protection.
当该协议启动时，它从较低级别协议接收会话标识符（这是来自第一个密钥交换的交换哈希H）。会话标识符唯一标识此会话，并适合签名以证明私钥的所有权。该协议还需要知道较低级别的协议是否提供机密性保护。
The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions.
这组文档的主要原始贡献者是：Tatu Ylonen、Tero Kivinen、Timo J.Rinne、Sami Lehtinen（SSH Communications Security Corp的所有成员）和Markku Juhani O.Saarinen（Jyvaskyla大学）。达伦·莫法特（Darren Moffat）是这组文件的原始编辑，也做出了重大贡献。
Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it.
多年来，许多人为本文件的编写做出了贡献。应该承认的人包括马茨·安德森、本·哈里斯、比尔·索末菲、布伦特·麦克卢尔、尼尔斯·莫勒、达米恩·米勒、德里克·福库斯、弗兰克·库萨克、海基·努西亚宁、雅各布·施莱特、杰夫·范·戴克、杰弗里·奥特曼、杰弗里·哈泽尔曼、乔恩·布莱特、约瑟夫·加尔布雷斯、肯·霍恩斯坦、马克斯·弗里德、马丁·福森、尼古拉斯·威廉姆斯、，Niels Provos、Perry Metzger、Peter Gutmann、Simon Josefsson、Simon Tatham、Wei Dai、Denis Bider、der Mouse和Tadayoshi Kohno。在这里列出他们的名字并不意味着他们认可这份文件，而是意味着他们对这份文件作出了贡献。
All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119].
所有与SSH协议相关的文件应使用关键字“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”来描述要求。这些关键字将按照[RFC2119]中所述进行解释。
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434].
当用于描述命名空间分配时，本文件中出现的关键词“私人使用”、“分层分配”、“先到先得”、“专家评审”、“所需规范”、“IESG批准”、“IETF共识”和“标准行动”应按照[RFC2434]中所述进行解释。
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
协议字段和可能的填充值在这组文档中定义。协议字段将在消息定义中定义。例如，SSH_MSG_CHANNEL_数据定义如下。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
字节SSH\U MSG\U通道数据uint32收件人通道字符串数据
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
在这些文档中，当引用字段时，它们将出现在单引号中。当引用填充这些字段的值时，它们将出现在双引号内。使用上述示例，“数据”的可能值为“foo”和“bar”。
The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server.
服务器通过告诉客户端在任何给定时间可以使用哪些身份验证方法继续交换来驱动身份验证。客户机可以自由地按任何顺序尝试服务器列出的方法。如果需要，这使服务器能够完全控制身份验证过程，但也为客户端提供了足够的灵活性，以便在服务器提供多种方法时，使用其支持的方法或对用户最方便的方法。
Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be granted access without any authentication, in which case, the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server.
按照[SSH-ARCH]中的定义，身份验证方法由其名称标识。“none”方法是保留的，不能列为受支持的方法。但是，它可以由客户端发送。服务器必须始终拒绝此请求，除非授予客户端无需任何身份验证的访问权限，在这种情况下，服务器必须接受此请求。发送此请求的主要目的是从服务器获取受支持方法的列表。
The server SHOULD have a timeout for authentication and disconnect if the authentication has not been accepted within the timeout period. The RECOMMENDED timeout period is 10 minutes. Additionally, the implementation SHOULD limit the number of failed authentication attempts a client may perform in a single session (the RECOMMENDED limit is 20 attempts). If the threshold is exceeded, the server SHOULD disconnect.
服务器应有一个身份验证超时时间，如果在超时时间内未接受身份验证，则应断开连接。建议的超时时间为10分钟。此外，实现应限制客户端在单个会话中可能执行的失败身份验证尝试次数（建议限制为20次尝试）。如果超过阈值，服务器应断开连接。
Additional thoughts about authentication timeouts and retries may be found in [ssh-1.2.30].
有关身份验证超时和重试的其他想法，请参见[ssh-1.2.30]。
All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method.
所有身份验证请求必须使用以下消息格式。仅定义了前几个字段；其余字段取决于身份验证方法。
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string method name in US-ASCII
.... method specific fields
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string method name in US-ASCII
.... method specific fields
The 'user name' and 'service name' are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated authentication states if they change. If it is unable to
“用户名”和“服务名”在每次新的身份验证尝试中都会重复，并且可能会更改。服务器实现必须在每条消息中仔细检查它们，如果它们发生变化，则必须清除任何累积的身份验证状态。如果不能
flush an authentication state, it MUST disconnect if the 'user name' or 'service name' changes.
刷新身份验证状态时，如果“用户名”或“服务名”发生更改，则必须断开连接。
The 'service name' specifies the service to start after authentication. There may be several different authenticated services provided. If the requested service is not available, the server MAY disconnect immediately or at any later time. Sending a proper disconnect message is RECOMMENDED. In any case, if the service does not exist, authentication MUST NOT be accepted.
“服务名称”指定身份验证后要启动的服务。可能会提供几种不同的经过身份验证的服务。如果请求的服务不可用，服务器可能会立即或在以后的任何时间断开连接。建议发送正确的断开信息。在任何情况下，如果服务不存在，则不能接受身份验证。
If the requested 'user name' does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentication 'method name' values, but never accept any. This makes it possible for the server to avoid disclosing information on which accounts exist. In any case, if the 'user name' does not exist, the authentication request MUST NOT be accepted.
如果请求的“用户名”不存在，服务器可能会断开连接，或者可能会发送可接受的身份验证“方法名称”值的虚假列表，但永远不会接受任何值。这使得服务器可以避免披露存在帐户的信息。在任何情况下，如果“用户名”不存在，则不得接受身份验证请求。
While there is usually little point for clients to send requests that the server does not list as acceptable, sending such requests is not an error, and the server SHOULD simply reject requests that it does not recognize.
虽然客户端发送服务器未列出为可接受的请求通常没有什么意义，但发送此类请求不是错误，服务器应该简单地拒绝它无法识别的请求。
An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication 'method name' used, and 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 following 'method name' values are defined.
定义了以下“方法名称”值。
"publickey" REQUIRED "password" OPTIONAL "hostbased" OPTIONAL "none" NOT RECOMMENDED
“公钥”必需“密码”可选“基于主机”可选“无”不推荐
Additional 'method name' values may be defined as specified in [SSH-ARCH] and [SSH-NUMBERS].
可以按照[SSH-ARCH]和[SSH-NUMBERS]中的规定定义其他“方法名称”值。
If the server rejects the authentication request, it MUST respond with the following:
如果服务器拒绝身份验证请求，则必须响应以下内容：
byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success
字节SSH\u MSG\u USERAUTH\u失败名称列表身份验证，可继续布尔部分成功
The 'authentications that can continue' is a comma-separated name-list of authentication 'method name' values that may productively continue the authentication dialog.
“可以继续的身份验证”是以逗号分隔的身份验证“方法名称”值的名称列表，可以有效地继续身份验证对话框。
It is RECOMMENDED that servers only include those 'method name' values in the name-list that are actually useful. However, it is not illegal to include 'method name' values that cannot be used to authenticate the user.
建议服务器在名称列表中只包含那些实际有用的“方法名称”值。但是，包含不能用于验证用户身份的“方法名称”值并不违法。
Already successfully completed authentications SHOULD NOT be included in the name-list, unless they should be performed again for some reason.
已成功完成的身份验证不应包含在名称列表中，除非出于某种原因应再次执行身份验证。
The value of 'partial success' MUST be TRUE if the authentication request to which this is a response was successful. It MUST be FALSE if the request was not successfully processed.
如果响应的身份验证请求成功，则“部分成功”的值必须为TRUE。如果请求未成功处理，则该值必须为FALSE。
When the server accepts authentication, it MUST respond with the following:
当服务器接受身份验证时，它必须响应以下命令：
byte SSH_MSG_USERAUTH_SUCCESS
字节SSH\u MSG\u USERAUTH\u成功
Note that this is not sent after each step in a multi-method authentication sequence, but only when the authentication is complete.
请注意，这不是在多方法身份验证序列中的每个步骤之后发送，而是仅在身份验证完成时发送。
The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST process each request completely and acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message before processing the next request.
客户端可以发送多个身份验证请求，而无需等待来自先前请求的响应。在处理下一个请求之前，服务器必须完全处理每个请求，并使用SSH_MSG_USERAUTH_失败消息确认任何失败的请求。
A request that requires further messages to be exchanged will be aborted by a subsequent request. A client MUST NOT send a subsequent request if it has not received a response from the server for a previous request. A SSH_MSG_USERAUTH_FAILURE message MUST NOT be sent for an aborted method.
需要进一步交换消息的请求将被后续请求中止。如果客户机没有收到服务器对前一请求的响应，则不得发送后续请求。对于中止的方法，不能发送SSH_MSG_USERAUTH_失败消息。
SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored.
SSH\u MSG\u USERAUTH\u SUCCESS只能发送一次。当SSH_MSG_USERAUTH_SUCCESS被发送时，在此之后收到的任何进一步的身份验证请求都应该被静默地忽略。
Any non-authentication messages sent by the client after the request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. Such messages can be identified by their message numbers (see Section 6).
在导致SSH_MSG_USERAUTH_成功发送的请求之后，客户端发送的任何非身份验证消息都必须传递给在此协议之上运行的服务。此类信息可通过其信息编号识别（见第6节）。
A client may request a list of authentication 'method name' values that may continue by using the "none" authentication 'method name'.
客户端可以请求身份验证“方法名称”值的列表，该列表可以通过使用“无”身份验证“方法名称”继续。
If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods that may continue in its 'authentications that can continue' value.
如果用户不需要身份验证，服务器必须返回SSH\u MSG\u USERAUTH\u SUCCESS。否则，服务器必须返回SSH_MSG_USERAUTH_FAILURE，并可能返回一个方法列表，这些方法可以在其“authentications that can continue”值中继续。
This 'method name' MUST NOT be listed as supported by the server.
此“方法名称”不能列为服务器支持的名称。
Authentication is complete when the server has responded with SSH_MSG_USERAUTH_SUCCESS. All authentication related messages received after sending this message SHOULD be silently ignored.
当服务器响应SSH\u MSG\u USERAUTH\u SUCCESS时，身份验证完成。发送此消息后收到的所有与身份验证相关的消息都应被静默忽略。
After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested service.
发送SSH_MSG_USERAUTH_SUCCESS后，服务器启动请求的服务。
In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from /etc/issue, use TCP wrappers, or similar software to display a banner before issuing a login prompt.
在某些司法管辖区，在认证前发送警告消息可能与获得法律保护有关。例如，许多UNIX机器通常显示/etc/issue中的文本，使用TCP包装器或类似软件在发出登录提示之前显示横幅。
The SSH server may send an SSH_MSG_USERAUTH_BANNER message at any time after this authentication protocol starts and before authentication is successful. This message contains text to be displayed to the client user before authentication is attempted. The format is as follows:
在该身份验证协议启动之后和身份验证成功之前，SSH服务器可以随时发送SSH_MSG_USERAUTH_横幅消息。此消息包含在尝试身份验证之前要向客户端用户显示的文本。格式如下:
byte SSH_MSG_USERAUTH_BANNER string message in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
ISO-10646 UTF-8编码[RFC3629]字符串语言标记[RFC3066]中的字节SSH\U MSG\U USERAUTH\U横幅字符串消息
By default, the client SHOULD display the 'message' on the screen. However, since the 'message' is likely to be sent for every login attempt, and since some client software will need to open a separate window for this warning, the client software may allow the user to explicitly disable the display of banners from the server. The 'message' may consist of multiple lines, with line breaks indicated by CRLF pairs.
默认情况下，客户端应在屏幕上显示“消息”。但是，由于每次登录尝试都可能发送“消息”，并且由于某些客户端软件需要为此警告打开单独的窗口，因此客户端软件可能允许用户明确禁用服务器上的横幅显示。“消息”可能由多行组成，换行符由CRLF对表示。
If the 'message' string is displayed, control character filtering, discussed in [SSH-ARCH], SHOULD be used to avoid attacks by sending terminal control characters.
如果显示“message”字符串，则应使用[SSH-ARCH]中讨论的控制字符过滤，通过发送终端控制字符来避免攻击。
All message numbers used by this authentication protocol are in the range from 50 to 79, which is part of the range reserved for protocols running on top of the SSH transport layer protocol.
此身份验证协议使用的所有消息编号都在50到79之间，这是为运行在SSH传输层协议之上的协议保留的范围的一部分。
Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting, preferably with a proper disconnect message sent to ease troubleshooting.
消息编号为80或更高的消息是为在该身份验证协议之后运行的协议保留的，因此在身份验证完成之前接收其中一个消息是错误的，服务器必须通过断开连接来响应该错误，最好发送适当的断开连接消息，以便于故障排除。
After successful authentication, such messages are passed to the higher-level service.
成功身份验证后，此类消息将传递给更高级别的服务。
These are the general authentication message codes:
以下是一般身份验证消息代码：
SSH_MSG_USERAUTH_REQUEST 50 SSH_MSG_USERAUTH_FAILURE 51 SSH_MSG_USERAUTH_SUCCESS 52 SSH_MSG_USERAUTH_BANNER 53
SSH\u MSG\u USERAUTH\u请求50 SSH\u MSG\u USERAUTH\u失败51 SSH\u MSG\u USERAUTH\u成功52 SSH\u MSG\u USERAUTH\u横幅53
In addition to the above, there is a range of message numbers (60 to 79) reserved for method-specific messages. These messages are only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). Different authentication methods reuse the same message numbers.
除上述内容外，还为特定于方法的消息保留了一系列消息编号（60到79）。这些消息仅由服务器发送（客户端仅发送SSH\u MSG\u USERAUTH\u请求消息）。不同的身份验证方法重用相同的消息编号。
The only REQUIRED authentication 'method name' is "publickey" authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in the near future.
唯一需要的身份验证“方法名称”是“公钥”身份验证。所有实现都必须支持这种方法；但是，并非所有用户都需要公钥，而且大多数本地策略在不久的将来不太可能要求对所有用户进行公钥身份验证。
With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the signature is valid. If both hold, the authentication request MUST be accepted; otherwise, it MUST be rejected. Note that the server MAY require additional authentications after successful authentication.
使用这种方法，私钥的拥有可以作为身份验证。此方法通过发送使用用户私钥创建的签名来工作。服务器必须检查密钥是否是用户的有效身份验证器，并且必须检查签名是否有效。如果两者都成立，则必须接受认证请求；否则，它必须被拒绝。请注意，成功验证后，服务器可能需要额外的验证。
Private keys are often stored in an encrypted form at the client host, and the user must supply a passphrase before the signature can be generated. Even if they are not, the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the "publickey" method would be acceptable.
私钥通常以加密形式存储在客户机主机上，用户必须在生成签名之前提供密码短语。即使不是，签名操作也会涉及一些昂贵的计算。为了避免不必要的处理和用户交互，提供了以下消息，用于查询使用“公钥”方法的身份验证是否可以接受。
byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string "publickey" boolean FALSE string public key algorithm name string public key blob
字节SSH_MSG_USERAUTH_请求字符串ISO-10646 UTF-8编码中的用户名[RFC3629]字符串服务名称US-ASCII字符串“公钥”布尔假字符串公钥算法名称字符串公钥blob
Public key algorithms are defined in the transport layer specification [SSH-TRANS]. The 'public key blob' may contain certificates.
公钥算法在传输层规范[SSH-TRANS]中定义。“公钥blob”可能包含证书。
Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange. If the server does not support some algorithm, it MUST simply reject the request.
可以提供任何公钥算法用于身份验证。特别是，该列表不受密钥交换期间协商内容的限制。如果服务器不支持某些算法，它必须简单地拒绝请求。
The server MUST respond to this message with either SSH_MSG_USERAUTH_FAILURE or with the following:
服务器必须以SSH_MSG_USERAUTH_失败或以下方式响应此消息：
byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request
字节SSH\u MSG\u USERAUTH\u PK\u OK string请求字符串公钥blob中的公钥算法名称
To perform actual authentication, the client MAY then send a signature generated using the private key. The client MAY send the signature directly without first verifying whether the key is acceptable. The signature is sent using the following packet:
为了执行实际的身份验证，客户端随后可以发送使用私钥生成的签名。客户端可以直接发送签名，而无需首先验证密钥是否可接受。使用以下数据包发送签名：
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication string signature
字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务名称字符串“publickey”布尔真字符串公钥算法名称字符串用于身份验证字符串签名的公钥
The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:
“签名”的值是由相应的私钥对以下数据按以下顺序进行的签名：
string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication
字符串会话标识符字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务名称字符串“publickey”布尔真字符串公钥算法名称字符串用于身份验证的公钥
When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct.
当服务器收到此消息时，它必须检查提供的密钥是否可用于身份验证，如果可以，则必须检查签名是否正确。
If both checks succeed, this method is successful. Note that the server may require additional authentications. The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed).
如果两个检查都成功，则此方法成功。请注意，服务器可能需要额外的身份验证。服务器必须以SSH_MSG_USERAUTH_SUCCESS（如果不需要更多身份验证）或SSH_MSG_USERAUTH_FAILURE（如果请求失败，或需要更多身份验证）响应。
The following method-specific message numbers are used by the "publickey" authentication method.
“公钥”身份验证方法使用以下特定于方法的消息编号。
SSH_MSG_USERAUTH_PK_OK 60
SSH\u MSG\u USERAUTH\u PK\u OK 60
Password authentication uses the following packets. Note that a server MAY request that a user change the password. All implementations SHOULD support password authentication.
密码验证使用以下数据包。请注意，服务器可能会请求用户更改密码。所有实现都应该支持密码身份验证。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "password" boolean FALSE string plaintext password in ISO-10646 UTF-8 encoding [RFC3629]
字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务名称字符串“密码”布尔值假字符串ISO-10646 UTF-8编码的明文密码[RFC3629]
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. It is up to the server how to interpret the password and validate it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords.
请注意，“明文密码”值采用ISO-10646 UTF-8编码。如何解释密码并根据密码数据库对其进行验证取决于服务器。但是，如果客户端以其他编码（例如ISO 8859-1-ISO拉丁语）读取密码，则必须在传输之前将密码转换为ISO-10646 UTF-8，并且服务器必须将密码转换为该系统上用于密码的编码。
From an internationalization standpoint, it is desired that if a user enters their password, the authentication process will work regardless of what OS and client software the user is using. Doing so requires normalization. Systems supporting non-ASCII passwords SHOULD always normalize passwords and user names whenever they are added to the database, or compared (with or without hashing) to existing entries in the database. SSH implementations that both store the passwords and compare them SHOULD use [RFC4013] for normalization.
从国际化的角度来看，如果用户输入密码，无论用户使用的是什么操作系统和客户端软件，都希望身份验证过程能够正常工作。这样做需要标准化。支持非ASCII密码的系统应始终规范化密码和用户名，无论何时将其添加到数据库中，或与数据库中的现有条目进行比较（有无散列）。存储密码并比较密码的SSH实现应该使用[RFC4013]进行规范化。
Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Both the server and the client should check whether the underlying transport layer provides confidentiality (i.e., if encryption is being used). If no confidentiality is provided ("none" cipher), password authentication SHOULD be disabled. If there is no confidentiality or no MAC, password change SHOULD be disabled.
注意，即使明文密码在数据包中传输，整个数据包也由传输层加密。服务器和客户端都应检查底层传输层是否提供机密性（即，是否使用加密）。如果未提供保密性（“无”密码），则应禁用密码身份验证。如果没有保密性或没有MAC，则应禁用密码更改。
Normally, the server responds to this message with success or failure. However, if the password has expired, the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In any case, the server MUST NOT allow an expired password to be used for authentication.
通常，服务器会成功或失败地响应此消息。但是，如果密码已过期，服务器应通过SSH\u MSG\u USERAUTH\u PASSWD\u CHANGEREQ响应来指示这一点。在任何情况下，服务器都不得允许使用过期密码进行身份验证。
byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
字节SSH\u MSG\u USERAUTH\u PASSWD\u CHANGEREQ字符串提示符，采用ISO-10646 UTF-8编码[RFC3629]字符串语言标记[RFC3066]
In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it.
在这种情况下，客户端可以继续使用不同的身份验证方法，或者从用户处请求新密码，然后使用以下消息重试密码身份验证。客户端也可以发送此消息，而不是正常的密码身份验证请求，而无需服务器请求。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "password" boolean TRUE string plaintext old password in ISO-10646 UTF-8 encoding [RFC3629] string plaintext new password in ISO-10646 UTF-8 encoding [RFC3629]
字节SSH\u MSG\u USERAUTH\u请求字符串用户名字符串服务名称字符串“密码”布尔真字符串明文ISO-10646 UTF-8编码旧密码[RFC3629]字符串明文ISO-10646 UTF-8编码新密码[RFC3629]
The server must reply to each request message with SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as follows:
服务器必须使用SSH\u MSG\u USERAUTH\u SUCCESS、SSH\u MSG\u USERAUTH\u FAILURE或另一个SSH\u MSG\u USERAUTH\u PASSWD\u CHANGEREQ回复每个请求消息。其含义如下：
SSH_MSG_USERAUTH_SUCCESS - The password has been changed, and authentication has been successfully completed.
SSH_MSG_USERAUTH_SUCCESS-密码已更改，身份验证已成功完成。
SSH_MSG_USERAUTH_FAILURE with partial success - The password has been changed, but more authentications are needed.
SSH_MSG_USERAUTH_失败，部分成功-密码已更改，但需要更多身份验证。
SSH_MSG_USERAUTH_FAILURE without partial success - The password has not been changed. Either password changing was not supported, or the old password was bad. Note that if the server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports changing the password.
SSH_MSG_USERAUTH_失败，但未部分成功-密码未更改。不支持更改密码，或者旧密码不正确。注意，如果服务器已经发送了SSH\u MSG\u USERAUTH\u PASSWD\u CHANGEREQ，我们知道它支持更改密码。
SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because the new password was not acceptable (e.g., too easy to guess).
SSH_MSG_USERAUTH_CHANGEREQ-密码未更改，因为新密码不可接受（例如，太容易猜测）。
The following method-specific message numbers are used by the password authentication method.
密码身份验证方法使用以下特定于方法的消息编号。
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
SSH\u MSG\u USERAUTH\u PASSWD\u CHANGEREQ 60
Some sites wish to allow authentication based on the host that the user is coming from and the user name on the remote host. While this form of authentication is not suitable for high-security sites, it can be very convenient in many environments. This form of authentication is OPTIONAL. When used, special care SHOULD be taken to prevent a regular user from obtaining the private host key.
有些站点希望允许基于用户来自的主机和远程主机上的用户名进行身份验证。虽然这种形式的身份验证不适用于高安全性站点，但在许多环境中都非常方便。这种形式的身份验证是可选的。使用时，应特别注意防止普通用户获取专用主机密钥。
The client requests this form of authentication by sending the following message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of authentication, except that the identity of the client host is checked more rigorously.
客户端通过发送以下消息请求这种形式的身份验证。它类似于UNIX的“rhosts”和“hosts.equiv”身份验证样式，只是更严格地检查客户机主机的身份。
This method works by having the client send a signature created with the private key of the client host, which the server checks with that host's public key. Once the client host's identity is established, authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name.
此方法的工作原理是让客户端发送使用客户端主机的私钥创建的签名，服务器使用该主机的公钥检查该签名。一旦建立了客户机主机的身份，将根据服务器和客户机上的用户名以及客户机主机名执行授权（但无需进一步验证）。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name expressed as the FQDN in US-ASCII string user name on the client host in ISO-10646 UTF-8 encoding [RFC3629] string signature
字节SSH_MSG_USERAUTH_请求字符串用户名字符串服务名称字符串“基于主机”字符串主机密钥字符串公钥算法客户端主机字符串公钥和证书客户端主机字符串客户端主机名以ISO-10646 UTF-8编码[RFC3629]字符串签名的客户端主机上的US-ASCII字符串用户名中的FQDN表示
Public key algorithm names for use in 'public key algorithm for host key' are defined in the transport layer specification [SSH-TRANS]. The 'public host key and certificates for client host' may include certificates.
“主机密钥的公钥算法”中使用的公钥算法名称在传输层规范[SSH-TRANS]中定义。“客户端主机的公共主机密钥和证书”可能包括证书。
The value of 'signature' is a signature with the private host key of the following data, in this order:
“签名”的值是具有以下数据的私有主机密钥的签名，顺序如下：
string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name expressed as the FQDN in US-ASCII string user name on the client host in ISO-10646 UTF-8 encoding [RFC3629]
字符串会话标识符字节SSH\U MSG\U USERAUTH\U请求字符串用户名字符串服务名称字符串“基于主机”字符串主机密钥的公钥算法字符串公用主机密钥和客户端主机字符串证书客户端主机名以ISO-10646 UTF-8编码的客户端主机上的US-ASCII字符串用户名中的FQDN表示[RFC3629]
The server MUST verify that the host key actually belongs to the client host named in the message, that the given user on that host is allowed to log in, and that the 'signature' value is a valid signature on the appropriate value by the given host key. The server MAY ignore the client 'user name', if it wants to authenticate only the client host.
服务器必须验证主机密钥是否确实属于消息中指定的客户端主机，该主机上的给定用户是否允许登录，以及“签名”值是否是给定主机密钥对相应值的有效签名。如果服务器只想验证客户端主机，则可以忽略客户端“用户名”。
Whenever possible, it is RECOMMENDED that the server perform additional checks to verify that the network address obtained from the (untrusted) network matches the given client host name. This makes exploiting compromised host keys more difficult. Note that this may require special handling for connections coming through a firewall.
只要可能，建议服务器执行其他检查，以验证从（不受信任的）网络获得的网络地址是否与给定的客户端主机名匹配。这使得利用受损主机密钥变得更加困难。请注意，这可能需要对通过防火墙的连接进行特殊处理。
This document is part of a set. The IANA considerations for the SSH protocol, as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and this document, are detailed in [SSH-NUMBERS].
本文件是一套文件的一部分。[SSH-ARCH]、[SSH-TRANS]、[SSH-CONNECT]和本文档中定义的SSH协议的IANA注意事项详见[SSH-NUMBERS]。
The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. The transport layer provides forward secrecy for password authentication and other methods that rely on secret data.
此协议的目的是执行客户端用户身份验证。它假设这通过安全传输层协议运行，该协议已经对服务器机器进行了身份验证，建立了加密的通信通道，并为此会话计算了唯一的会话标识符。传输层为密码验证和其他依赖机密数据的方法提供前向保密性。
Full security considerations for this protocol are provided in [SSH-ARCH].
[SSH-ARCH]中提供了此协议的完整安全注意事项。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-CONNECT]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）连接协议”，RFC 42542006年1月。
[SSH-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月。
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS]Lehtinen，S.和C.Lonvick，Ed.，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[ssh-1.2.30] Ylonen, T., "ssh-1.2.30/RFC", File within compressed tarball ftp://ftp.funet.fi/pub/unix/security/login/ ssh/ssh-1.2.30.tar.gz, November 1995.
[ssh-1.2.30]Ylonen，T.，“ssh-1.2.30/RFC”，压缩tarball中的文件ftp://ftp.funet.fi/pub/unix/security/login/ ssh/ssh-1.2.30.tar.gz，1995年11月。
Authors' Addresses
作者地址
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
芬兰赫尔辛基塔图伊洛宁SSH通信安全公司Valimotie 17 00380
EMail: ylo@ssh.com
EMail: ylo@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
Chris Lonvick（编辑）思科系统公司，研究大道12515号。美国奥斯汀78759
EMail: clonvick@cisco.com
EMail: clonvick@cisco.com
Trademark Notice
商标公告
"ssh" is a registered trademark in the United States and/or other countries.
“ssh”是美国和/或其他国家/地区的注册商标。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。