RFC4252 日本語訳

Network Working Group                                          T. Ylonen
Request for Comments: 4252              SSH Communications Security Corp
Category: Standards Track                                C. Lonvick, Ed.
                                                     Cisco Systems, Inc.
                                                            January 2006

Ylonenがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4252年のセキュアシェル (SSH)通信秘密保全Corpカテゴリ: エド標準化過程C.Lonvick、シスコシステムズInc.2006年1月

             The Secure Shell (SSH) Authentication Protocol

セキュア・シェル(セキュアシェル (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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(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.

Secureシェルプロトコル(SSH)は不安定なネットワークの上の安全なリモート・ログインと他の安全なネットワーク・サービスのためのプロトコルです。 このドキュメントはSSH認証プロトコルフレームワーク、公開鍵、パスワード、およびホストベースのクライアント認証方法を説明します。 追加認証方法は別々のドキュメントで説明されます。 SSH認証プロトコルは、SSHトランスポート層プロトコルの上で稼働していて、単一の認証されたトンネルをSSH接続プロトコルに提供します。

Ylonen & Lonvick            Standards Track                     [Page 1]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[1ページ]。

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. 序論…2 2. 貢献者…3 3. このドキュメントで中古のコンベンション…3 4. 認証プロトコルフレームワーク…4 5. 認証要求…4 5.1. 認証要求への応答…5 5.2. 「なにも」認証要求…7 5.3. ユーザー認証の完成…7 5.4. バナーメッセージ…7 6. 認証プロトコルメッセージ番号…8 7. 公開鍵認証方法: 「パブリックキー」…8 8. パスワード認証メソッド: 「パスワード」…10 9. ホストベースの認証: 「hostbasedしました」…12 10. IANA問題…14 11. セキュリティ問題…14 12. 参照…15 12.1. 標準の参照…15 12.2. 有益な参照…15人の作者のアドレス…16 通知を商標登録してください…16

1.  Introduction

1. 序論

   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]を読んだ後の書き込み禁止であるべきです。 このドキュメントはアーキテクチャドキュメントから参照も詳細な説明なしで用語と記法を自由に使用します。

   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です)。 セッション識別子は、唯一このセッションを特定して、秘密鍵の所有権を立証するために署名するのに適当です。 また、このプロトコルは、低い平らなプロトコルが秘密性保護を提供するかどうかを知る必要があります。

Ylonen & Lonvick            Standards Track                     [Page 2]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[2ページ]。

2.  Contributors

2. 貢献者

   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、ティモ・J.リンネ、サミ・レーティネン(セキュアシェル (SSH)通信秘密保全Corpのすべて)、およびマルック-Juhani O.サーリネン(ユベスキュレ大学)。 ダーレン・モファットは、このセットのドキュメントの元のエディタであり、また、非常にかなりの貢献をしました。

   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.

多くの人々が数年間このドキュメントの開発に貢献しました。 承認されるべきである人々はマッツ・アンデション、ベン・ハリス、ビル・ゾンマーフェルト、ブレント・マクルーア、ニールズ・モーラー、ダミアン・ミラー、デリックFawcus、フランク・キューザック、Heikki Nousiainen、ジェイコブSchlyter、ジェフ・ヴァンダイク、ジェフリー・アルトマン、ジェフリーHutzelman、ジョンBright、ジョゼフ・ガルブレイス、ケン・ホーンスタイン、マーカス・フリードル、マーチンForssen、ニコラス・ウィリアムズ、ニールズProvos、ペリーメッツガー、ピーター・ガットマン、サイモンJosefsson、サイモンTatham、ウェイDai、デニスBider、der Mouse、および河野忠義を入れます。 ここにそれらの名前を記載するのは、彼らがこのドキュメントに裏書きしますが、それに貢献したことを意味しません。

3.  Conventions Used in This Document

3. 本書では使用されるコンベンション

   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プロトコルに関連するすべてのドキュメントが“MUST"、「必須NOT」が「必要である」というキーワードを使用するものとします、“SHALL"、「」、“SHOULD"、「「推薦され」て、要件について説明するために「5月」の、そして、「任意」のNOTはそうするべきです。 これらのキーワードは[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_エムエスジー_CHANNEL_DATAは以下の通り定義されます。

      byte      SSH_MSG_CHANNEL_DATA
      uint32    recipient channel
      string    data

バイトSSH_エムエスジー_CHANNEL_DATA 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"と「バー」です。

Ylonen & Lonvick            Standards Track                     [Page 3]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[3ページ]。

4.  The Authentication Protocol Framework

4. 認証プロトコルフレームワーク

   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]で定義されるようにそれらの名前によって特定されます。 「なにも」メソッドは、予約されていて、サポートされるように記載されているはずがありません。 しかしながら、それはクライアントによって送られるかもしれません。 少しも認証なしでクライアントのアクセスを承諾してはいけないなら、サーバはいつもこの要求を拒絶しなければなりません、その場合、サーバがこの要求を受け入れなければなりません。 この要求を送る主な目的はサーバからサポートしているメソッドのリストを得ることです。

   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.

サーバSHOULDは認証のためのタイムアウトを持って、認証がタイムアウト時間中に受け入れられていないなら、切断します。 RECOMMENDEDタイムアウト時間は10分です。 さらに、実装SHOULDはクライアントがただ一つのセッションのときに実行するかもしれない失敗した認証試みの数を制限します(RECOMMENDED限界は20の試みです)。 敷居が超えられているなら、サーバSHOULDは切断します。

   Additional thoughts about authentication timeouts and retries may be
   found in [ssh-1.2.30].

認証タイムアウトと再試行に関する追加考えは[セキュアシェル (SSH)-1.2.30]で見つけられるかもしれません。

5.  Authentication Requests

5. 認証要求

   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

SSH_エムエスジー_USERAUTH_REQUESTストリングユーザが中で米国-ASCIIにおける米国-ASCIIストリングメソッド名の[RFC3629]ストリングサービス名をコード化するISO-10646 UTF-8と命名するバイト… メソッド詳細分野

   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

'ユーザ名'と'サービス名'は、あらゆる新しい認証試みで繰り返されて、変化するかもしれません。 サーバ実装は、あらゆるメッセージで丹念にそれらをチェックしなければならなくて、変化するなら、どんな蓄積された認証州も洗い流さなければなりません。 それであることができません。

Ylonen & Lonvick            Standards Track                     [Page 4]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[4ページ]。

   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.

'サービス名'は、認証の後に始まるようにサービスを指定します。 提供されたいくつかの異なった認証されたサービスがあるかもしれません。 要求されたサービスが利用可能でないなら、サーバはすぐにか後の何時でも切断するかもしれません。 適切な分離メッセージを送るのは、RECOMMENDEDです。 どのような場合でも、サービスが存在していないなら、認証を受け入れてはいけません。

   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.

クライアントがサーバが許容できるとして記載しないという要求を送るように、通常少ないポイントがありますが、そのような要求を送るのは、誤りではありません、そして、サーバSHOULDは単に、それが認識しない要求を拒絶します。

   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.

認証要求はメッセージのさらなる交換をもたらすかもしれません。 そのようなすべてのメッセージが使用という認証'メソッド名'によって、どれがサーバをケースに入れるかで、クライアントは、何時でも5月に新しいSSH_エムエスジー_USERAUTH_REQUESTメッセージを続行して、前の認証試みを捨てて、新しい方を続行しなければなりません。

   The following 'method name' values are defined.

以下の'メソッド名'値は定義されます。

      "publickey"             REQUIRED
      "password"              OPTIONAL
      "hostbased"             OPTIONAL
      "none"                  NOT RECOMMENDED

必要な「パスワード」任意の"hostbasedする"の任意の「なにも」が推薦しなかった「パブリックキー」

   Additional 'method name' values may be defined as specified in
   [SSH-ARCH] and [SSH-NUMBERS].

値が定義されるかもしれない追加'メソッド名'は[SSH-ARCH]と[SSH-民数記]で指定しました。

5.1.  Responses to Authentication Requests

5.1. 認証要求への応答

   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_エムエスジー_USERAUTH_FAILURE人名簿認証

Ylonen & Lonvick            Standards Track                     [Page 5]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[5ページ]。

   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.

サーバが人名簿のそれらの実際に役に立つ'メソッド名'値を含んでいるだけであるのは、RECOMMENDEDです。 しかしながら、ユーザを認証するのに使用できない'メソッド名'値を含んでいるのは不法ではありません。

   Already successfully completed authentications SHOULD NOT be included
   in the name-list, unless they should be performed again for some
   reason.

既に首尾よく完成した認証SHOULD NOTが人名簿に含まれていて、いくつかのために再びそれらを実行しないなら、推論してください。

   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)_エムエスジー_USERAUTH_成功

   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_エムエスジー_USERAUTH_FAILUREメッセージで各要求を完全に処理して、どんな失敗した要求も承諾しなければなりません。

   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_エムエスジー_USERAUTH_FAILUREメッセージを送ってはいけません。

   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_エムエスジーUSERAUTH_SUCCESS MUST、一度だけ送ってください。 _SSH_エムエスジーであるときに、無視されて、そのSHOULDが静かに受けた後にどんなさらなる認証要求も、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_エムエスジーUSERAUTH_SUCCESSをもたらした送られる要求の後にクライアントによって送られたどんな非認証メッセージもこのプロトコルの上で実行されるサービスに通過しなければなりません。 それらのメッセージ番号でそのようなメッセージを特定できます(セクション6を見てください)。

Ylonen & Lonvick            Standards Track                     [Page 6]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[6ページ]。

5.2.  The "none" Authentication Request

5.2. 「なにも」認証要求

   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_エムエスジーUSERAUTH_SUCCESSを返さなければなりません。 さもなければ、サーバは、_SSH_エムエスジーUSERAUTH_FAILUREを返さなければならなくて、それと共に'続くことができる認証'値で続くかもしれないメソッドのリストを返すかもしれません。

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

この'メソッド名'はサーバによってサポートされるように記載されているはずがありません。

5.3.  Completion of User Authentication

5.3. ユーザー認証の完成

   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_エムエスジーUSERAUTH_SUCCESSと共に反応したとき、認証は完全です。 すべての認証が無視されていた状態でこのメッセージを送って、SHOULDが静かに受け取った後に受け取るメッセージについて話しました。

   After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the
   requested service.

_SSH_エムエスジーUSERAUTH_SUCCESSを送った後に、サーバは要求されたサービスを始めます。

5.4.  Banner Message

5.4. バナーメッセージ

   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_エムエスジー_USERAUTH_BANNERメッセージを送るかもしれません。 このメッセージは認証が試みられる前にクライアントユーザに表示されるべきテキストを含んでいます。 形式は以下の通りです:

      byte      SSH_MSG_USERAUTH_BANNER
      string    message in ISO-10646 UTF-8 encoding [RFC3629]
      string    language tag [RFC3066]

[RFC3629]ストリング言語タグをコード化するISO-10646 UTF-8のバイトSSH_エムエスジー_USERAUTH_BANNERストリングメッセージ[RFC3066]

   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.

デフォルトで、クライアントSHOULDはスクリーンに'メッセージ'を表示します。 しかしながら、'メッセージ'があらゆるログイン試みのために送られそうであって、何らかのクライアントソフトウェアが、この警告のために別々の窓を開ける必要があるので、ユーザはクライアントソフトウェアでサーバからバナーのディスプレイを明らかに無効にすることができるかもしれません。'メッセージ'は複数の系列から成るかもしれません、ラインブレイクがCRLF組によって示されている状態で。

Ylonen & Lonvick            Standards Track                     [Page 7]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[7ページ]。

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

ストリングが表示された制御文字フィルタリングであるという[SSH-ARCH]で議論された'メッセージ'SHOULDであるなら使用されて、送付の端末の制御文字で攻撃を避けてください。

6.  Authentication Protocol Message Numbers

6. 認証プロトコルメッセージ番号

   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と、より高いこの認証プロトコルを追いかけるプロトコルのために予約されるので受信している1つのメッセージ番号は誤りです、トラブルシューティングを緩和するために望ましくは、適切な分離メッセージを送って。(サーバは、切断することによって、それに反応しなければなりません)。

   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)_エムエスジー_USERAUTH_要求50セキュアシェル (SSH)_エムエスジー_のUSERAUTH_故障51セキュアシェル (SSH)_エムエスジー_USERAUTH_成功52セキュアシェル (SSH)_エムエスジー_USERAUTH_バナー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)があります。 サーバはこれらのメッセージを送るだけです(クライアントは_USERAUTH_REQUESTメッセージをSSH_エムエスジーだけに送ります)。 異なった認証方法は同じメッセージ番号を再利用します。

7.  Public Key Authentication Method: "publickey"

7. 公開鍵認証方法: 「パブリックキー」

   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.

唯一のREQUIRED認証'メソッド名'は「パブリックキー」認証です。 すべての実装がこのメソッドをサポートしなければなりません。 しかしながら..ユーザ..必要..持つ..公開鍵..地方..方針..ありそう..必要..公開鍵..認証..ユーザ..目前

   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.

このメソッドで、秘密鍵の所有物は認証として機能します。 このメソッドは、ユーザの秘密鍵で作成された署名を送ることによって、利きます。 サーバは、キーがユーザにとって、有効な固有識別文字であることをチェックしなければならなくて、署名が有効であることをチェックしなければなりません。 両方が成立するなら、認証要求を受け入れなければなりません。 さもなければ、それを拒絶しなければなりません。 サーバが次々と追加うまくいっている認証を必要とするかもしれないことに注意してください。

Ylonen & Lonvick            Standards Track                     [Page 8]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[8ページ]。

   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_エムエスジー_USERAUTH_REQUESTストリングユーザが米国-ASCIIストリング「パブリックキー」論理演算子FALSEストリング公開鍵アルゴリズム名前ストリング公開鍵一滴の[RFC3629]ストリングサービス名をコード化するISO-10646 UTF-8で命名するバイト

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

公開鍵アルゴリズムはトランスポート層仕様[SSH-TRANS]に基づき定義されます。 '公開鍵一滴'は証明書を含むかもしれません。

   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_エムエスジーUSERAUTH_FAILUREか以下でこのメッセージに反応しなければなりません:

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

SSH_エムエスジー_USERAUTH_PK_OKストリング公開鍵アルゴリズムが要求ストリング公開鍵一滴から要求から命名するバイト

   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_エムエスジー_USERAUTH_REQUESTストリングユーザ名前ストリングサービスは、認証ストリング署名に使用されるためにストリング「パブリックキー」論理演算子TRUEストリング公開鍵アルゴリズム名前ストリング公開鍵を命名します。

Ylonen & Lonvick            Standards Track                     [Page 9]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[9ページ]。

   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_エムエスジー_USERAUTH_REQUESTストリングユーザ名前ストリングサービスは、認証に使用されるためにストリング「パブリックキー」論理演算子TRUEストリング公開鍵アルゴリズム名前ストリング公開鍵を命名します。

   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_エムエスジーの_USERAUTH_SUCCESS(それ以上の認証は全く必要でないなら)、または_SSH_エムエスジーUSERAUTH_FAILUREと共に反応しなければなりません(要求が失敗したか、または、より多くの認証が必要であるなら)。

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

以下のメソッド特有のメッセージ番号は「パブリックキー」認証方法で使用されます。

      SSH_MSG_USERAUTH_PK_OK              60

セキュアシェル (SSH)_エムエスジー_USERAUTH_PK_OK60

8.  Password Authentication Method: "password"

8. パスワード認証メソッド: 「パスワード」

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

パスワード認証は以下のパケットを使用します。 サーバが、ユーザがパスワードを変えるよう要求するかもしれないことに注意してください。 すべての実装SHOULDがパスワード認証をサポートします。

      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]

ISO-10646 UTF-8コード化におけるバイトSSH_エムエスジー_USERAUTH_REQUESTストリングユーザ名前ストリングサービス名ストリング「パスワード」論理演算子FALSEストリング平文パスワード[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でコード化されることに注意してください。 サーバまでそれはそうです。パスワードを解釈して、パスワードデータベースに対してそれを有効にする方法。 しかしながら、クライアントがある他のコード化(例えば、ISO8859-1--ISO Latin1)におけるパスワードを読むなら、伝わる前にパスワードをISO-10646 UTF-8に変換しなければなりません、そして、サーバはパスワードのそのシステムの上で使用されるコード化にパスワードを変換しなければなりません。

Ylonen & Lonvick            Standards Track                    [Page 10]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[10ページ]。

   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.

国際化見地から、ユーザがそれらのパスワードを入力すると、認証過程がユーザが使用しているすべてのOSとクライアントソフトウェアにかかわらず働くことが望まれています。 そうするのは正常化を必要とします。 それらがデータベースに追加されるか、またはデータベースで既存のエントリーと比較される(論じ尽くすことのあるなしにかかわらず)ときはいつも、非ASCIIパスワードがSHOULDであるとサポートするシステムがいつもパスワードとユーザ名を正常にします。 それは、パスワードを保存して、それらを比較します。SSH実装、SHOULDは正常化に[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.

cleartextパスワードがパケットで伝えられますが、全体のパケットがトランスポート層によって暗号化されることに注意してください。 サーバとクライアントの両方が、基本的なトランスポート層が秘密性を提供するかどうか(すなわち、暗号化が使用されているなら)チェックするべきです。 (「なにも」暗号)、パスワード認証SHOULDは障害があるならどんな秘密性もそうでないなら。 どんな秘密性がないのもMACもなければ、パスワードはSHOULDを変えます。無効にされます。

   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.

通常、サーバは成否でこのメッセージに反応します。 しかしながら、パスワードが期限が切れたなら、サーバSHOULDは、_SSH_エムエスジーUSERAUTH_PASSWD_CHANGEREQと共に応じることによって、これを示します。 どのような場合でも、サーバは、満期のパスワードが認証に使用されるのを許容してはいけません。

      byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
      string    prompt in ISO-10646 UTF-8 encoding [RFC3629]
      string    language tag [RFC3066]

SSH_エムエスジー_USERAUTH_PASSWD_CHANGEREQストリングが[RFC3629]ストリング言語タグをコード化するISO-10646 UTF-8でうながすバイト[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_エムエスジー_USERAUTH_REQUESTストリングユーザ名前ストリングサービス名ストリング「パスワード」論理演算子TRUEはISO-10646 UTF-8コード化における[RFC3629]ストリング平文の新しいパスワードをコード化するISO-10646 UTF-8の平文の古いパスワードを結びます。[RFC3629]

Ylonen & Lonvick            Standards Track                    [Page 11]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[11ページ]。

   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_エムエスジーUSERAUTH_SUCCESS、_SSH_エムエスジーUSERAUTH_FAILURE、または_別のSSH_エムエスジーUSERAUTH_PASSWD_CHANGEREQと共に各要求メッセージに答えなければなりません。 これらの意味は以下の通りです:

      SSH_MSG_USERAUTH_SUCCESS - The password has been changed, and
      authentication has been successfully completed.

SSH_、エムエスジー_USERAUTH_SUCCESS--パスワードを変えて、首尾よく認証を終了しました。

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

SSH_エムエスジー_、部分的な成功があるUSERAUTH_FAILURE--パスワードを変えましたが、より多くの認証を必要とします。

      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_エムエスジー_、部分的な成功のないUSERAUTH_FAILURE--パスワードは変えられていません。 パスワード変化がサポートされなかったか、または古いパスワードは悪かったです。 サーバが既に_SSH_エムエスジーUSERAUTH_PASSWD_CHANGEREQを送ったなら、私たちが、それが、変化がパスワードであるとサポートするのを知っていることに注意してください。

      SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because
      the new password was not acceptable (e.g., too easy to guess).

_SSH_エムエスジーUSERAUTH_CHANGEREQ、--、新しいパスワードが許容できなかったのでパスワードが変えられなかった(例えば、推測するのにおいてあまりたやすい)

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

以下のメソッド特有のメッセージ番号はパスワード認証方法で使用されます。

      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   60

セキュアシェル (SSH)、_エムエスジー_USERAUTH_PASSWD_CHANGEREQ60

9.  Host-Based Authentication: "hostbased"

9. ホストベースの認証: 「hostbasedしました」。

   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.

いくつかのサイトがリモートホストの上でユーザが来る予定であるホストとユーザ名に基づく認証を許したがっています。 この形式の認証が高セキュリティサイトに適していない間、それは多くの環境で非常に便利である場合があります。 この形式の認証はOPTIONALです。 中古の、そして、特別な注意SHOULDであるときには取って、愛用者が個人的なホストキーを入手するのを防いでください。

   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.

クライアントにサーバがそのホストの公開鍵に問い合わせるクライアントホストの秘密鍵で作成された署名を送らせることによって、このメソッドは利きます。 クライアントホストのアイデンティティがいったん確立されると、承認(しかし、さらなる認証がない)はサーバとクライアントの上のユーザ名、およびクライアントホスト名に基づいて実行されます。

Ylonen & Lonvick            Standards Track                    [Page 12]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[12ページ]。

      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_エムエスジー_USERAUTH_REQUESTストリングユーザ名前ストリングサービスは米国-ASCIIにおけるFQDNが[RFC3629]ストリング署名をコード化するISO-10646 UTF-8のクライアントホストにユーザ名を結ぶので表されたクライアントホストストリングクライアントホスト名にちなんでホストキーストリングのためのストリングが「hostbasedされた」というストリング公開鍵アルゴリズムを公共のホストキーと証明書と命名します。

   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_エムエスジー_USERAUTH_REQUESTストリングユーザ名前ストリングサービスは米国-ASCIIにおけるFQDNがISO-10646 UTF-8コード化でユーザ名をクライアントホストに結ぶので表されたクライアントホストストリングクライアントホスト名にちなんでホストキーストリングのためのストリングが「hostbasedされた」というストリング公開鍵アルゴリズムを公共のホストキーと証明書と命名します。[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.

可能であるときはいつも、サーバがネットワーク・アドレスが(信頼されていない)のネットワークマッチから与えられたクライアントホスト名を得たことを確かめるために追加チェックを実行するのは、RECOMMENDEDです。 これで、感染されたホストキーを利用するのは、より難しくなります。 これがファイアウォールを通り抜ける接続のために特別な取り扱いを必要とするかもしれないことに注意してください。

Ylonen & Lonvick            Standards Track                    [Page 13]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[13ページ]。

10.  IANA Considerations

10. IANA問題

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

このドキュメントは1セットの一部です。 SSHプロトコルのための[SSH-ARCH]、[SSH-TRANS]、[SSH-CONNECT]、およびこのドキュメントで定義されるIANA問題は[SSH-民数記]で詳細です。

11.  Security Considerations

11. セキュリティ問題

   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]に提供します。

Ylonen & Lonvick            Standards Track                    [Page 14]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[14ページ]。

12.  References

12. 参照

12.1.  Normative References

12.1. 引用規格

   [SSH-ARCH]    Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
                 Protocol Architecture", RFC 4251, January 2006.

[セキュアシェル (SSH)アーチ] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、1月2006日

   [SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
                 Connection Protocol", RFC 4254, January 2006.

[セキュアシェル (SSH)で接続します] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))接続プロトコル」、RFC4254、1月2006日

   [SSH-TRANS]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
                 Transport Layer Protocol", RFC 4253, January 2006.

[セキュアシェル (SSH)、-、移-、]、YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、1月2006日

   [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
                 (SSH) Protocol Assigned Numbers", RFC 4250, January
                 2006.

[セキュアシェル (SSH)番号] レーティネンとS.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコル規定番号」、RFC4250、1月2006日

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC3066]     Alvestrand, H., "Tags for the Identification of
                 Languages", BCP 47, RFC 3066, January 2001.

[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。

   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日

   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
                 Names and Passwords", RFC 4013, February 2005.

[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。

12.2.  Informative References

12.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」、Fileはtarball ftp://ftp.funet.fi/pub/unix/security/login/ セキュアシェル (SSH)セキュアシェル (SSH)/1.2.30.tar.gz、1995年11月を中に圧縮しました。

Ylonen & Lonvick            Standards Track                    [Page 15]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[15ページ]。

Authors' Addresses

作者のアドレス

   Tatu Ylonen
   SSH Communications Security Corp
   Valimotie 17
   00380 Helsinki
   Finland

Tatu Ylonenセキュアシェル (SSH)通信秘密保全Corp Valimotie17 00380ヘルシンキフィンランド

   EMail: ylo@ssh.com

メール: ylo@ssh.com

   Chris Lonvick (editor)
   Cisco Systems, Inc.
   12515 Research Blvd.
   Austin  78759
   USA

クリスLonvick(エディタ)シスコシステムズInc.12515研究Blvd. オースチン78759米国

   EMail: clonvick@cisco.com

メール: clonvick@cisco.com

Trademark Notice

商標表示

   "ssh" is a registered trademark in the United States and/or other
   countries.

「セキュアシェル (SSH)」は合衆国、そして/または、他国で登録商標です。

Ylonen & Lonvick            Standards Track                    [Page 16]

RFC 4252              SSH Authentication Protocol           January 2006

Ylonen&Lonvick規格はセキュアシェル (SSH)認証プロトコル2006年1月にRFC4252を追跡します[16ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Ylonen & Lonvick            Standards Track                    [Page 17]

Ylonen&Lonvick標準化過程[17ページ]