draft-ietf-secsh-userauth-18.txt

来自「OTP是开放电信平台的简称」· 文本 代码 · 共 896 行 · 第 1/3 页

   SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method.

   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.

   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 Message Numbers
   (Section 3.2)).

3.1.3 The "none" Authentication Request

   A client may request a list of authentication methods that may
   continue by using the "none" authentication method.

   If no authentication at all 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
   authentication methods that can continue.

   This method MUST NOT be listed as supported by the server.

3.1.4 Completion of User Authentication

   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.

   After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the
   requested service.




Ylonen & Moffat          Expires March 2, 2003                  [Page 6]

Internet-Draft        SSH Authentication Protocol         September 2002


3.1.5 Banner Message

   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',
   or use "tcp wrappers" or similar software to display a banner before
   issuing a login prompt.

   The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time
   before authentication is successful.  This message contains text to
   be displayed to the client user before authentication is attempted.
   The format is as follows:

     byte      SSH_MSG_USERAUTH_BANNER
     string    message (ISO-10646 UTF-8)
     string    language tag (as defined in [RFC3066])

   The client SHOULD by default 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.

   If the message string is displayed, control character filtering
   discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending
   terminal control characters.

3.2 Authentication Protocol Message Numbers

   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.

   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 first to ease troubleshooting).

   After successful authentication, such messages are passed to the
   higher-level service.

   These are the general authentication message codes:

     #define SSH_MSG_USERAUTH_REQUEST            50
     #define SSH_MSG_USERAUTH_FAILURE            51
     #define SSH_MSG_USERAUTH_SUCCESS            52



Ylonen & Moffat          Expires March 2, 2003                  [Page 7]

Internet-Draft        SSH Authentication Protocol         September 2002


     #define SSH_MSG_USERAUTH_BANNER             53

   In addition to the above, there is a range of message numbers
   (60..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.

3.3 Public Key Authentication Method: publickey

   The only REQUIRED authentication method is public key 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 key would be acceptable.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "publickey"
     boolean   FALSE
     string    public key algorithm name
     string    public key blob

   Public key algorithms are defined in the transport layer
   specification [SSH-TRANS]. The public key blob may contain
   certificates.

   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



Ylonen & Moffat          Expires March 2, 2003                  [Page 8]

Internet-Draft        SSH Authentication Protocol         September 2002


   SSH_MSG_USERAUTH_FAILURE or with the following:

     byte      SSH_MSG_USERAUTH_PK_OK
     string    public key algorithm name from the request
     string    public key blob from the request

   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
     string    "publickey"
     boolean   TRUE
     string    public key algorithm name
     string    public key to be used for authentication
     string    signature

   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
     string    "publickey"
     boolean   TRUE
     string    public key algorithm name
     string    public key to be used for authentication

   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).

   The following method-specific message numbers are used by the
   publickey authentication method.

     /* Key-based */
     #define SSH_MSG_USERAUTH_PK_OK              60




Ylonen & Moffat          Expires March 2, 2003                  [Page 9]

Internet-Draft        SSH Authentication Protocol         September 2002


3.4 Password Authentication Method: password

   Password authentication uses the following packets.  Note that a
   server MAY request the user to change the password.  All
   implementations SHOULD support password authentication.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "password"
     boolean   FALSE
     string    plaintext password (ISO-10646 UTF-8)

   Note that the password is encoded in ISO-10646 UTF-8.  It is up to
   the server how it interprets the password and validates 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.

   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.

   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 anycase the server MUST NOT allow an expired password to be used
   for authentication.

     byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
     string    prompt (ISO-10646 UTF-8)
     string    language tag (as defined in [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



Ylonen & Moffat          Expires March 2, 2003                 [Page 10]

Internet-Draft        SSH Authentication Protocol         September 2002


     string    "password"
     boolean   TRUE
     string    plaintext old password (ISO-10646 UTF-8)
     string    plaintext new password (ISO-10646 UTF-8)

   The server must reply to 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_MSG_USERAUTH_SUCCESS The password has been changed, and
      authentication has been successfully completed.

      SSH_MSG_USERAUTH_FAILURE with partial success The password has
      been changed, but more authentications are needed.

      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_CHANGEREQ The password was not changed because
      the new password was not acceptable (e.g. too easy to guess).

   The following method-specific message numbers are used by the
   password authentication method.

     #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   60


3.5 Host-Based Authentication: hostbased

   Some sites wish to allow authentication based on the host where the