[要約] RFC 4256は、Secure Shell Protocol (SSH) における汎用的なメッセージ交換認証メカニズムを定義しています。この文書は、SSH接続中にユーザー認証情報を安全に交換するためのフレームワークを提供し、特にキーボードインタラクティブ認証プロセスに焦点を当てています。利用場面としては、多要素認証やカスタム認証方法をSSHセッションに統合する際に特に有用です。関連するRFCには、SSHプロトコルを定義するRFC 4251（SSHプロトコルアーキテクチャ）、RFC 4252（SSH認証プロトコル）、RFC 4253（SSHトランスポート層プロトコル）などがあります。
Network Working Group F. Cusack
Request for Comments: 4256 savecore.net
Category: Standards Track M. Forssen
AppGate Network Security AB
January 2006
Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
セキュアシェルプロトコル（SSH）の汎用メッセージ交換認証
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s).
セキュアシェルプロトコル（SSH）は、安全でないリモートログインおよびその他の安全なネットワークサービスを安全でないネットワーク上で行うためのプロトコルです。このドキュメントでは、キーボード（または同等の英数字入力デバイス）を介して認証データを入力する必要がある対話型認証に適した、SSHプロトコルの汎用認証方法について説明します。この方法の主な目的は、SSHクライアントが実際の認証メカニズムの詳細を知らなくても、認証メカニズムのクラス全体をサポートできるようにすることです。
The SSH authentication protocol [SSH-USERAUTH] is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection.
SSH認証プロトコル[SSH-USERAUTH]は、汎用のユーザー認証プロトコルです。これは、SSHトランスポート層プロトコル[SSH-TRANS]で実行することを目的としています。認証プロトコルは、基盤となるプロトコルが整合性と機密性の保護を提供することを前提としています。
This document describes a general purpose authentication method for the SSH authentication protocol. This method is suitable for interactive authentication methods that do not need any special software support on the client side. Instead, all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code.
このドキュメントでは、SSH認証プロトコルの汎用認証方法について説明します。この方法は、クライアント側で特別なソフトウェアサポートを必要としないインタラクティブな認証方法に適しています。代わりに、すべての認証データをキーボードから入力する必要があります。この方法の主な目的は、SSHクライアントが、SSHサーバーで使用される基礎となる認証メカニズムの詳細をほとんどまたはまったく認識できないようにすることです。これにより、サーバーは、クライアントコードを更新しなくても、基盤となる認証メカニズムを任意に選択または変更できます。
The name for this authentication method is "keyboard-interactive".
この認証方法の名前は「keyboard-interactive」です。
This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation.
このドキュメントは、SSHアーキテクチャドキュメント[SSH-ARCH]およびSSH認証ドキュメント[SSH-USERAUTH]を読んだ後にのみ読む必要があります。このドキュメントでは、参照や詳細な説明なしに、両方のドキュメントの用語と表記法を自由に使用しています。
This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is described here anyway because some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations.
このドキュメントでは、認証情報を取得する際のクライアントとユーザーとのやり取りについても説明します。これは多少プロトコル仕様の範囲外ですが、プロトコルの一部の側面はユーザーインターフェイスの問題に基づいて特別に設計されているため、ここで説明します。この情報を省略すると、互換性がないかぎこちない実装になる可能性があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC-2119]で説明されているように解釈されます。
Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. This makes it difficult to add new mechanisms for authentication as all clients must be updated to support the new mechanism. With the generic method defined here, clients will not require code changes to support new authentication mechanisms, and if a separate authentication layer is used, such as [PAM], then the server may not need any code changes either.
現在定義されているSSHの認証方法は、基礎となる認証メカニズムと密接に結び付いています。新しいメカニズムをサポートするためにすべてのクライアントを更新する必要があるため、認証のための新しいメカニズムを追加することが困難になります。ここで定義された一般的な方法では、クライアントは新しい認証メカニズムをサポートするためにコードを変更する必要がなく、[PAM]などの別の認証レイヤーが使用されている場合、サーバーもコードを変更する必要がない場合があります。
This presents a significant advantage to other methods, such as the "password" method (defined in [SSH-USERAUTH]), as new (presumably stronger) methods may be added "at will" and system security can be transparently enhanced.
これは、（[SSH-USERAUTH]で定義された）「パスワード」メソッドなどの他のメソッドに大きな利点をもたらします。新しい（おそらくより強力な）メソッドが「随意に」追加され、システムのセキュリティが透過的に強化されるためです。
Challenge-response and One Time Password mechanisms are also easily supported with this authentication method.
この認証方法では、チャレンジ/レスポンスおよびワンタイムパスワードのメカニズムも簡単にサポートされます。
However, this authentication method is limited to authentication mechanisms that do not require any special code, such as hardware drivers or password mangling, on the client.
ただし、この認証方法は、クライアントでハードウェアドライバーやパスワードマングリングなどの特別なコードを必要としない認証メカニズムに限定されます。
The client initiates the authentication with an SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with an SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with an SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client.
クライアントは、SSH_MSG_USERAUTH_REQUESTメッセージを使用して認証を開始します。次にサーバーは、SSH_MSG_USERAUTH_INFO_REQUESTメッセージでクライアントに認証情報を要求します。クライアントはユーザーから情報を取得し、SSM_MSG_USERAUTH_INFO_RESPONSEメッセージで応答します。サーバーは、クライアントから回答を受け取る前に、別のSSH_MSG_USERAUTH_INFO_REQUESTを送信してはなりません（MUST NOT）。
The authentication starts with the client sending the following packet:
認証は、クライアントが次のパケットを送信することから始まります。
byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8)
バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名（ISO-10646 UTF-8、[RFC-3629]で定義）文字列サービス名（US-ASCII）文字列 "keyboard-interactive"（US-ASCII）文字列言語タグ（[RFC-3 -3066]）文字列サブメソッド（ISO-10646 UTF-8）
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language to be used based on the tags communicated during key exchange [SSH-TRANS].
言語タグは非推奨であり、空の文字列である必要があります。この仕様の将来の改訂で削除される可能性があります。代わりに、サーバーは、鍵交換中に通信されるタグ[SSH-TRANS]に基づいて、使用する言語を選択する必要があります（SHOULD）。
If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
言語タグが空の文字列でない場合、サーバーはこのプロトコルの一部としてクライアントに送信されるすべてのメッセージに指定された言語を使用する必要があります（SHOULD）。言語タグは、このプロトコル外のメッセージの言語選択には使用しないでください。サーバーが要求された言語をサポートしていない場合、使用される言語は実装に依存します。
The submethods field is included so the user can give a hint of which actual methods he wants to use. It is a comma-separated list of authentication submethods (software or hardware) that the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise, it MUST send the empty string.
submethodsフィールドが含まれているので、ユーザーは使用したい実際のメソッドのヒントを提供できます。これは、ユーザーが希望する認証サブメソッド（ソフトウェアまたはハードウェア）のコンマ区切りのリストです。おそらく構成設定を通じて、ユーザーが推奨するサブメソッドをクライアントが知っている場合は、サブメソッドフィールドを使用してこの情報をサーバーに渡すことができます（MAY）。それ以外の場合は、空の文字列を送信する必要があります。
The actual names of the submethods is something the user and the server need to agree upon.
サブメソッドの実際の名前は、ユーザーとサーバーが同意する必要があるものです。
Server interpretation of the submethods field is implementation-dependent.
サブメソッドフィールドのサーバー解釈は実装に依存します。
One possible implementation strategy of the submethods field on the server is that, unless the user may use multiple different submethods, the server ignores this field. If the user may authenticate using one of several different submethods, the server should treat the submethods field as a hint on which submethod the user wants to use this time.
サーバー上のサブメソッドフィールドの1つの可能な実装戦略は、ユーザーが複数の異なるサブメソッドを使用しない限り、サーバーがこのフィールドを無視することです。ユーザーがいくつかの異なるサブメソッドの1つを使用して認証する場合、サーバーはサブメソッドフィールドを、ユーザーが今回使用したいサブメソッドのヒントとして扱う必要があります。
Note that when this message is sent to the server, the client has not yet prompted the user for a password, and so that information is NOT included with this initial message (unlike the "password" method).
このメッセージがサーバーに送信されるとき、クライアントはまだユーザーにパスワードの入力を求めていないため、（「password」メソッドとは異なり）この初期メッセージには情報が含まれていません。
The server MUST reply with an SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
サーバーは、SSH_MSG_USERAUTH_SUCCESS、SSH_MSG_USERAUTH_FAILURE、またはSSH_MSG_USERAUTH_INFO_REQUESTメッセージで応答する必要があります。
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead, it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s), which look just like the one(s) that would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid usernames by comparing the results when authenticating as different users.
失敗がユーザー名またはサービス名に基づいている場合、サーバーはSSH_MSG_USERAUTH_FAILUREメッセージで応答しないでください。代わりに、SSH_MSG_USERAUTH_INFO_REQUESTメッセージを送信する必要があります。これは、認証を続行する必要がある場合に送信されるメッセージと同様に、失敗メッセージを送信します（適切な遅延の後、以下に説明します）。目標は、異なるユーザーとして認証するときの結果を比較することにより、有効なユーザー名を見つけられないようにすることです。
The server MAY reply with an SSH_MSG_USERAUTH_SUCCESS message if no authentication is required for the user in question. However, a better approach, for reasons discussed above, might be to reply with an SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate) the response.
問題のユーザーに認証が必要ない場合、サーバーはSSH_MSG_USERAUTH_SUCCESSメッセージで応答してもよい（MAY）。ただし、上記の理由により、SSH_MSG_USERAUTH_INFO_REQUESTメッセージで応答し、その応答を無視（検証しない）することをお勧めします。
Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message.
リクエストは、SSH_MSG_USERAUTH_INFO_REQUESTメッセージを使用してサーバーから生成されます。
The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However, the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may not send another request before the client has answered.
サーバーは、クライアントの認証に必要な数の要求を送信できます。クライアントは、複数の交換を処理できるように準備する必要があります。ただし、サーバーで複数のSSH_MSG_USERAUTH_INFO_REQUESTメッセージが未処理であってはなりません。つまり、クライアントが応答する前に別の要求を送信することはできません。
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
SSH_MSG_USERAUTH_INFO_REQUESTメッセージは次のように定義されます。
byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts]
バイトSSH_MSG_USERAUTH_INFO_REQUEST文字列名（ISO-10646 UTF-8）文字列命令（ISO-10646 UTF-8）文字列言語タグ（[RFC-3066]で定義）int num-prompts string prompt [1]（ISO-10646 UTF- 8）boolean echo [1] ... string prompt [num-prompts]（ISO-10646 UTF-8）boolean echo [num-prompts]
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language used based on the tags communicated during key exchange [SSH-TRANS].
言語タグは非推奨であり、空の文字列である必要があります。この仕様の将来の改訂で削除される可能性があります。代わりに、サーバーは、鍵交換中に通信されるタグ[SSH-TRANS]に基づいて、使用する言語を選択する必要があります（SHOULD）。
If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
言語タグが空の文字列でない場合、サーバーはこのプロトコルの一部としてクライアントに送信されるすべてのメッセージに指定された言語を使用する必要があります（SHOULD）。言語タグは、このプロトコル外のメッセージの言語選択には使用しないでください。サーバーが要求された言語をサポートしていない場合、使用される言語は実装に依存します。
The server SHOULD take into consideration that some clients may not be able to properly display a long name or prompt field (see next section), and limit the lengths of those fields if possible. For example, instead of an instruction field of "Enter Password" and a prompt field of "Password for user23@host.domain: ", a better choice might be an instruction field of "Password authentication for user23@host.domain" and a prompt field of "Password: ". It is expected that this authentication method would typically be backended by [PAM] and so such choices would not be possible.
サーバーは、一部のクライアントが長い名前またはプロンプトフィールド（次のセクションを参照）を適切に表示できない可能性があることを考慮に入れ、可能な場合はそれらのフィールドの長さを制限する必要があります。たとえば、「Enter Password」の指示フィールドと「user23@host.domainのパスワード」のプロンプトフィールドの代わりに、「user23@host.domainのパスワード認証」の指示フィールドと「パスワード：」のプロンプトフィールド。この認証方法は通常[PAM]によってバックエンドされることが予想されるため、このような選択は不可能です。
The name and instruction fields MAY be empty strings; the client MUST be prepared to handle this correctly. The prompt field(s) MUST NOT be empty strings.
名前と指示フィールドは空の文字列であるかもしれません。クライアントはこれを正しく処理する準備ができていなければなりません。プロンプトフィールドは空の文字列であってはなりません。
The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below).
num-promptsフィールドは「0」の場合があります。その場合、メッセージにはプロンプト/エコーフィールドはありませんが、クライアントは（下記のように）名前と指示フィールドを表示する必要があります（SHOULD）。
Upon receiving a request message, the client SHOULD prompt the user as follows:
リクエストメッセージを受信すると、クライアントは次のようにユーザーにプロンプトを表示する必要があります（SHOULD）。
A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then, for each prompt in turn, the client SHOULD display the prompt and read the user input.
コマンドラインインターフェース（CLI）クライアントは、名前と指示を（空でない場合）出力して、改行を追加する必要があります（SHOULD）。次に、各プロンプトについて、クライアントはプロンプトを表示し、ユーザー入力を読み取る必要があります（SHOULD）。
A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user. For example, an implementation SHOULD NOT discard the name field because its windows lack titles; instead, it SHOULD find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window.
グラフィカルユーザーインターフェイス（GUI）クライアントには、ユーザーにプロンプトを表示する方法について多くの選択肢があります。 1つの可能性は、プロンプトが表示されるダイアログウィンドウのタイトルとして、名前フィールド（アプリケーション名が前に付いている可能性があります）を使用することです。そのダイアログウィンドウでは、指示フィールドはテキストメッセージになり、プロンプトはテキスト入力フィールドのラベルになります。すべてのフィールドをユーザーに提示する必要があります。たとえば、ウィンドウにはタイトルがないため、実装では名前フィールドを破棄しないでください。代わりに、この情報を表示する別の方法を見つける必要があります。プロンプトがダイアログウィンドウに表示される場合、クライアントは各プロンプトを個別のウィンドウに表示しないでください。
All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occurred. The instruction field SHOULD NOT be truncated.
すべてのクライアントは、改行が埋め込まれた命令フィールドを適切に処理する必要があります。また、名前とプロンプトに少なくとも30文字を表示できる必要があります（SHOULD）。サーバーが名前を提示するか、30文字を超えるプロンプトを表示する場合、クライアントはこれらのフィールドを表示できる長さに切り詰めることができます（MAY）。クライアントがフィールドを切り捨てる場合、そのような切り捨てが発生したことを明確に示す必要があります。命令フィールドは切り捨てないでください。
Clients SHOULD use control character filtering, as discussed in [SSH-ARCH], to avoid attacks by including terminal control characters in the fields to be displayed.
クライアントは、[SSH-ARCH]で説明されているように、制御文字フィルタリングを使用して、表示されるフィールドに端末制御文字を含めることで攻撃を回避する必要があります（SHOULD）。
For each prompt, the corresponding echo field indicates whether the
user input should be echoed as characters are typed. Clients SHOULD
correctly echo/mask user input for each prompt independently of other
prompts in the request message. If a client does not honor the echo
field for whatever reason, then the client MUST err on the side of
masking input. A GUI client might like to have a checkbox toggling
echo/mask. Clients SHOULD NOT add any additional characters to the
prompt, such as ": " (colon-space); the server is responsible for
supplying all text to be displayed to the user. Clients MUST also
accept empty responses from the user and pass them on as empty
strings.
After obtaining the requested information from the user, the client MUST respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message.
ユーザーから要求された情報を取得した後、クライアントはSSH_MSG_USERAUTH_INFO_RESPONSEメッセージで応答する必要があります。
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows:
SSH_MSG_USERAUTH_INFO_RESPONSEメッセージの形式は次のとおりです。
byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8)
バイトSSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response [1]（ISO-10646 UTF-8）... string response [num-responses]（ISO-10646 UTF-8）
Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting.
応答はISO-10646 UTF-8でエンコードされていることに注意してください。応答を解釈して検証する方法はサーバーに依存します。ただし、クライアントが他のエンコーディング（ISO 8859-1など）で応答を読み取る場合は、送信前に応答をISO-10646 UTF-8に変換する必要があります。
From an internationalization standpoint, it is desired that if a user enters responses, the authentication process will work regardless of what OS and client software they are using. Doing so requires normalization. Systems supporting non-ASCII passwords SHOULD always normalize passwords and usernames whenever they are added to the database, or compare them (with or without hashing) to existing entries in the database. SSH implementations that both store the passwords and compare them SHOULD use [SASLPREP] for normalization.
国際化の観点からは、ユーザーが応答を入力した場合、使用しているOSやクライアントソフトウェアに関係なく、認証プロセスが機能することが望まれます。そのためには正規化が必要です。非ASCIIパスワードをサポートするシステムは、パスワードとユーザー名がデータベースに追加されるときは常にそれらを常に正規化するか、またはそれらを（ハッシュありまたはなしで）データベース内の既存のエントリと比較する必要があります。パスワードの保存と比較の両方を行うSSH実装は、正規化に[SASLPREP]を使用する必要があります（SHOULD）。
If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message.
num-responsesフィールドが要求メッセージのnum-promptsフィールドと一致しない場合、サーバーは失敗メッセージを送信する必要があります。
In the case that the server sends a `0' num-prompts field in the request message, the client MUST send a response message with a `0' num-responses field to complete the exchange.
サーバーが要求メッセージで「0」のnum-promptsフィールドを送信する場合、クライアントは交換を完了するために「0」のnum-responsesフィールドを含む応答メッセージを送信する必要があります。
The responses MUST be ordered as the prompts were ordered. That is, response[n] MUST be the answer to prompt[n].
プロンプトが順序付けられたときに応答を順序付けする必要があります。つまり、response [n]は、prompt [n]に対する回答でなければなりません。
After receiving the response, the server MUST send either an SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message.
応答を受信した後、サーバーはSSH_MSG_USERAUTH_SUCCESS、SSH_MSG_USERAUTH_FAILURE、または別のSSH_MSG_USERAUTH_INFO_REQUESTメッセージを送信する必要があります。
If the server fails to authenticate the user (through the underlying authentication mechanism(s)), it SHOULD NOT send another request message(s) in an attempt to obtain new authentication data; instead, it SHOULD send a failure message. The only time the server should send multiple request messages is if additional authentication data is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user).
サーバーが（基礎となる認証メカニズムを介して）ユーザーの認証に失敗した場合、新しい認証データを取得しようとして、別の要求メッセージを送信してはなりません（SHOULD NOT）。代わりに、失敗メッセージを送信する必要があります。サーバーが複数の要求メッセージを送信する必要があるのは、追加の認証データが必要な場合のみです（つまり、ユーザーの認証に使用する必要のある複数の基本的な認証メカニズムがあるため）。
If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending it to the client. It is suspected that implementations are likely to make the time delay configurable; a suggested default is 2 seconds.
サーバーが失敗メッセージで応答するつもりである場合、それをクライアントに送信する前に、実装に依存する時間だけ遅延する場合があります。実装によって時間遅延が構成可能になる可能性が高いと考えられます。推奨されるデフォルトは2秒です。
Here are two example exchanges between a client and server. The first is an example of challenge/response with a handheld token. This is an authentication that is not otherwise possible with other authentication methods.
次に、クライアントとサーバー間の2つの交換例を示します。 1つ目は、ハンドヘルドトークンを使用したチャレンジ/レスポンスの例です。これは、他の認証方法では不可能な認証です。
C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string ""
C：バイトSSH_MSG_USERAUTH_REQUEST C：文字列 "user23" C：文字列 "ssh-userauth" C：文字列 "keyboard-interactive" C：文字列 "" C：文字列 ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "CRYPTOCard Authentication" S: string "The challenge is '14315716'" S: string "en-US" S: int 1 S: string "Response: " S: boolean TRUE
S：バイトSSH_MSG_USERAUTH_INFO_REQUEST S：文字列 "CRYPTOCard Authentication" S：文字列 "チャレンジは '14315716'" S：文字列 "en-US" S：int 1 S：文字列 "Response：" S：ブール値TRUE
[Client prompts user for password]
[クライアントはユーザーにパスワードを要求する]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "6d757575"
C：バイトSSH_MSG_USERAUTH_INFO_RESPONSE C：整数1 C：文字列 "6d757575"
S: byte SSH_MSG_USERAUTH_SUCCESS
S：バイトSSH_MSG_USERAUTH_SUCCESS
The second example is a standard password authentication; in this case, the user's password is expired.
2番目の例は、標準のパスワード認証です。この場合、ユーザーのパスワードは期限切れになります。
C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "en-US" C: string ""
C：バイトSSH_MSG_USERAUTH_REQUEST C：文字列 "user23" C：文字列 "ssh-userauth" C：文字列 "keyboard-interactive" C：文字列 "en-US" C：文字列 ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Authentication" S: string "" S: string "en-US" S: int 1 S: string "Password: " S: boolean FALSE
S：バイトSSH_MSG_USERAUTH_INFO_REQUEST S：文字列 "パスワード認証" S：文字列 "" S：文字列 "en-US" S：整数1 S：文字列 "パスワード：" S：ブールFALSE
[Client prompts user for password]
[クライアントはユーザーにパスワードを要求する]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "password"
C：バイトSSH_MSG_USERAUTH_INFO_RESPONSE C：整数1 C：文字列「パスワード」
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired."
S: string "en-US"
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
[Client prompts user for new password]
[クライアントはユーザーに新しいパスワードを要求する]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 2 C: string "newpass" C: string "newpass"
C：バイトSSH_MSG_USERAUTH_INFO_RESPONSE C：整数2 C：文字列 "newpass" C：文字列 "newpass"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password changed" S: string "Password successfully changed for user23." S: string "en-US" S: int 0
S：バイトSSH_MSG_USERAUTH_INFO_REQUEST S：文字列 "パスワードが変更されました" S：文字列 "user23のパスワードが正常に変更されました。" S：文字列 "en-US" S：整数0
[Client displays message to user]
[クライアントはユーザーにメッセージを表示します]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0
C：バイトSSH_MSG_USERAUTH_INFO_RESPONSE C：整数0
S: byte SSH_MSG_USERAUTH_SUCCESS
S：バイトSSH_MSG_USERAUTH_SUCCESS
The userauth type "keyboard-interactive" is used for this authentication method.
この認証方法には、userauthタイプ「keyboard-interactive」が使用されます。
The following method-specific constants are used with this authentication method:
この認証方法では、次のメソッド固有の定数が使用されます。
SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61
SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61
The authentication protocol and this authentication method depend on the security of the underlying SSH transport layer. Without the confidentiality provided therein, any authentication data passed with this method is subject to interception.
認証プロトコルとこの認証方法は、基盤となるSSHトランスポート層のセキュリティに依存します。機密性が提供されていない場合、この方法で渡される認証データは傍受される可能性があります。
The number of client-server exchanges required to complete an authentication using this method may be variable. It is possible that an observer may gain valuable information simply by counting that number. For example, an observer may guess that a user's password has expired, and with further observation may be able to determine the password lifetime imposed by a site's password expiration policy.
この方法を使用して認証を完了するために必要なクライアント/サーバー交換の数は、変動する場合があります。単にその数を数えるだけで、オブザーバーが貴重な情報を得る可能性があります。たとえば、オブザーバーはユーザーのパスワードの有効期限が切れていると推測し、さらに観察すると、サイトのパスワード有効期限ポリシーによって課されたパスワードの有効期間を判断できる場合があります。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC-3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC-3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、2006年1月。
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANS] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、2006年1月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPREP] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995.
[PAM] Samar、V.、Schemers、R。、「Pluggable Authentication Modules（PAM）による統合ログイン」、OSF RFC 86.0、1995年10月。
Authors' Addresses
著者のアドレス
Frank Cusack savecore.net
フランクキューザックsavecore.net
EMail: frank@savecore.net
Martin Forssen AppGate Network Security AB Otterhallegatan 2 SE-411 18 Gothenburg SWEDEN
Martin Forssen AppGate Network Security AB Otterhallegatan 2 SE-411 18ヨーテボリスウェーデン
EMail: maf@appgate.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（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事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンライン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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。