RFC4256 日本語訳
4256 Generic Message Exchange Authentication for the Secure ShellProtocol (SSH). F. Cusack, M. Forssen. January 2006. (Format: TXT=24728 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Cusack
Request for Comments: 4256 savecore.net
Category: Standards Track M. Forssen
AppGate Network Security AB
January 2006
コメントを求めるワーキンググループF.キューザック要求をネットワークでつないでください: 4256savecore.net Category: 標準化過程M.Forssen AppGateネットワークセキュリティAB2006年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(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 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).
Secureシェルプロトコル(SSH)は不安定なネットワークの上の安全なリモート・ログインと他の安全なネットワーク・サービスのためのプロトコルです。 認証データがキーボード(または、同等な英数字の入力装置)を通して入力されるべきであるところでこのドキュメントは対話的な認証に適したSSHプロトコルのための汎用の認証方法を説明します。 このメソッドの主要な目標はSSHクライアントが実際の認証機構の詳細を知らないで全体のクラスの認証機構をサポートするのを許容することです。
1. Introduction
1. 序論
The SSH authentication protocol [SSH-USERAUTH] is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection.
SSH認証プロトコル[SSH-USERAUTH]は汎用ユーザー認証プロトコルです。 SSHトランスポート層プロトコルの上に実行されるのは意図しています[SSH-TRANS]。 認証プロトコルは、基本的なプロトコルが保全と秘密性保護を提供すると仮定します。
This document describes a general purpose authentication method for the SSH authentication protocol. This method is suitable for interactive authentication methods that do not need any special software support on the client side. Instead, all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of
このドキュメントはSSH認証プロトコルのために汎用の認証方法を説明します。 このメソッドはクライアント側における少しの特別なソフトウェアサポートも必要としない対話的な認証方法に適しています。 代わりに、すべての認証データがキーボードを通して入力されるべきです。 まず知識を持っていないSSHクライアントを許容するメソッドがことであるこの主要な目標
Cusack & Forssen Standards Track [Page 1] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[1ページ]。
the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code.
. これがそうするSSHサーバによって使用される基本的な認証機構の詳細で、クライアントコードをアップデートする必要はなくて、サーバは、任意に基本的な認証機構を選択するか、または変えます。
The name for this authentication method is "keyboard-interactive".
この認証方法のための名前は「キーボード対話的です」。
This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation.
このドキュメントはSSHアーキテクチャドキュメント[SSH-ARCH]とSSH認証ドキュメント[SSH-USERAUTH]を読んだ後の書き込み禁止であるべきです。 このドキュメントは両方のドキュメントから参照も詳細な説明なしで用語と記法を自由に使用します。
This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is described here anyway because some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations.
また、このドキュメントはユーザと共に認証情報を得る際にクライアントとの対話のいくつかについて説明します。 プロトコル仕様の範囲のいくらか外にこれがある間、プロトコルのいくつかの局面がユーザーインタフェース問題に基づいて明確に設計されていて、この情報を省略するのが非互換であるか厄介な実装に通じるかもしれないので、それはここでとにかく説明されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
2. Rationale
2. 原理
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.
また、チャレンジレスポンスとOne Time Passwordメカニズムはこの認証方法で容易にサポートされます。
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.
しかしながら、この認証方法は少しの特別なコードも必要としない認証機構に制限されます、ハードウェア・ドライバーかパスワードの台無しにするように、クライアントの上で。
Cusack & Forssen Standards Track [Page 2] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[2ページ]。
3. Protocol Exchanges
3. プロトコル交換
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_エムエスジー_USERAUTH_REQUESTメッセージで認証を開始します。 そして、サーバはSSH_エムエスジー_USERAUTH_INFO_REQUESTメッセージでクライアントから認証情報を要求します。 クライアントは、ユーザから情報を得て、次に、SSM_エムエスジー_USERAUTH_INFO_RESPONSEメッセージで応じます。 クライアントから答えを受ける前にサーバは_別のSSH_エムエスジーUSERAUTH_INFO_REQUESTを送ってはいけません。
3.1. Initial Exchange
3.1. 初期の交換
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_エムエスジー_USERAUTH_REQUESTストリングユーザ名(中で定義されるとしてのISO-10646 UTF-8[RFC-3629])のストリングサービス名(米国-ASCII)ストリング「キーボードインタラクティブ」(米国-ASCII)ストリング言語タグ([RFC-3066]で定義されるように)ストリング「副-メソッド」(ISO-10646 UTF-8)
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language to be used based on the tags communicated during key exchange [SSH-TRANS].
言語タグが推奨しない、SHOULD、空のストリングになってください。 この仕様の今後の改正でそれを取り除くかもしれません。 代わりに、サーバSHOULDは、言語が主要な交換[SSH-TRANS]の間に伝えられたタグに基づいて使用されるのを選択します。
If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
言語タグが空のストリングでないなら、サーバSHOULDはこのプロトコルの一部としてクライアントに送られたどんなメッセージにも指定された言語を使用します。 言語はSHOULD NOTにタグ付けをします。メッセージのための言語選択には、このプロトコルの外で使用されてください。 サーバが要求された言語をサポートしないなら、使用されるべき言語は実装依存しています。
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.
ユーザが彼がどの実際のメソッドを使用したがっているかに関するヒントを与えることができるように、「副-メソッド」分野は含まれています。 それはユーザが好む認証「副-メソッド」(ソフトウェアかハードウェア)のコンマで切り離されたリストです。 クライアントがユーザにおそらく構成設定を通して「副-メソッド」に関する知識を好ませるなら、それは、この情報をサーバに通過するのに「副-メソッド」分野を使用するかもしれません。さもなければ、空のストリングを送らなければなりません。
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.
「副-メソッド」分野のサーバ解釈は実装に依存しています。
Cusack & Forssen Standards Track [Page 3] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[3ページ]。
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).
このメッセージをサーバに送るとき、クライアントがパスワードのためにその情報がこの初期のメッセージ(「パスワード」メソッドと異なった)で入れられていないようにまだユーザをうながしていないことに注意してください。
The server MUST reply with an SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
サーバは_SSH_エムエスジー_USERAUTH_SUCCESS、SSH_エムエスジーUSERAUTH_FAILUREとの回答、またはSSH_エムエスジー_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.
失敗がユーザ名かサービス名に基づいているなら、サーバSHOULD NOTはSSH_エムエスジー_USERAUTH_FAILUREメッセージで返答します。 代わりにそれ、SHOULDは_USERAUTH_INFO_REQUESTメッセージをSSH_エムエスジーに送ります。(それは、まさしく認証が失敗メッセージを続いて、次に送るべきである場合で送られたもの(s)(以下で説明されるとしての適当な遅れの後の)に似ています)。 目標は異なったユーザとして認証するとき結果を比較することによって有効なユーザ名を見つけるのを不可能にすることです。
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_エムエスジー_USERAUTH_SUCCESSメッセージで返答するかもしれません。 しかしながら、より良いアプローチが上で議論した理由で、USERAUTH_INFO_REQUESTが通信して、無視するSSH_エムエスジー_で返答することであるかもしれない、(有効にしない、)、応答。
3.2. Information Requests
3.2. 情報要求
Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message.
要求は、サーバからSSH_エムエスジー_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.
サーバはクライアントを認証するという必要なだけの要求を送るかもしれません。 クライアントは複数の交換を扱う用意ができていなければなりません。 しかしながら、サーバには、未払いの1つ以上のSSH_エムエスジー_USERAUTH_INFO_REQUESTメッセージがあってはいけません。 クライアントが答える前にすなわち、それは別の要求を送らないかもしれません。
Cusack & Forssen Standards Track [Page 4] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[4ページ]。
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
SSH_エムエスジー_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_エムエスジー_USERAUTH_INFO_REQUESTストリング名(ISO-10646 UTF-8)のストリング指示(ISO-10646 UTF-8)ストリング言語タグ([RFC-3066]で定義されるように)int num-プロンプトストリング迅速な[1](ISO-10646 UTF-8)論理演算子エコー[1]…ストリングプロンプト[num-プロンプト](ISO-10646 UTF-8)論理演算子エコー[num-プロンプト]
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language used based on the tags communicated during key exchange [SSH-TRANS].
言語タグが推奨しない、SHOULD、空のストリングになってください。 この仕様の今後の改正でそれを取り除くかもしれません。 代わりに、サーバSHOULDは主要な交換[SSH-TRANS]の間に伝えられたタグに基づいて使用される言語を選択します。
If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
言語タグが空のストリングでないなら、サーバSHOULDはこのプロトコルの一部としてクライアントに送られたどんなメッセージにも指定された言語を使用します。 言語はSHOULD NOTにタグ付けをします。メッセージのための言語選択には、このプロトコルの外で使用されてください。 サーバが要求された言語をサポートしないなら、使用されるべき言語は実装依存しています。
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.
サーバSHOULDは、何人かのクライアントが適切に、長い名前か迅速な野原(次のセクションを見る)を表示して、できれば、それらの分野の長さを制限できないかもしれないのを考慮に入れます。 例えば「パスワードを入力してください」の指示分野と迅速な分野の代わりに「 user23@host.domain のためのパスワード:」 「より良い選択が「 user23@host.domain のためのパスワード認証」の指示分野と迅速な分野であるかもしれない、「パスワード:」 ". この認証方法が[PAM]によって通常backendedされると予想されて、そのような選択は可能でないでしょう。
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-プロンプト分野が'0'であるかもしれない、その場合、メッセージにはプロンプト/エコー分野が全くないでしょうが、クライアントSHOULDはまだ名前と指示野原を表示しています(以下で説明されるように)。
Cusack & Forssen Standards Track [Page 5] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[5ページ]。
3.3. User Interface
3.3. ユーザーインタフェース
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つの可能性はプロンプトが提示される対話ウィンドウのタイトルとして名前欄(ことによるとアプリケーションの名前で前に置かれている)を使用することです。 その対話ウィンドウでは、指示分野はテキストメッセージでしょう、そして、プロンプトはテキストエントリー分野へのラベルでしょう。 すべてがSHOULDをさばきます。ユーザに寄贈します。 例えば、窓がタイトルを欠いているので、実装SHOULD NOTは名前欄を捨てます。 代わりにそれ、SHOULDはこの情報を表示する別の方法を見つけます。 プロンプトが対話ウィンドウに提示されるなら、クライアントSHOULD NOTは別々の窓の各プロンプトを提示します。
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.
すべてのクライアントが埋め込まれたニューラインで適切に指示分野を扱わなければなりません。 それら、SHOULD、また、少なくとも30のキャラクタを名前とプロンプトに見せることができてください。 サーバが30のキャラクタより長い間名前かプロンプトを提示するなら、クライアントはそれが表示できる長さにこれらの分野に先端を切らせるかもしれません。 クライアントが何か分野に先端を切らせるなら、そのようなトランケーションが起こったという明白な指示があるに違いありません。 指示はSHOULD NOTをさばきます。先端を切られます。
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.
クライアントSHOULDは制御文字フィルタリングを使用します、表示するためにその分野に端末の制御文字を含んでいることによって攻撃を避けるために[SSH-ARCH]で議論するように。
For each prompt, the corresponding echo field indicates whether the user input should be echoed as characters are typed. Clients SHOULD correctly echo/mask user input for each prompt independently of other prompts in the request message. If a client does not honor the echo field for whatever reason, then the client MUST err on the side of masking input. A GUI client might like to have a checkbox toggling echo/mask. Clients SHOULD NOT add any additional characters to the prompt, such as ": " (colon-space); the server is responsible for supplying all text to be displayed to the user. Clients MUST also accept empty responses from the user and pass them on as empty strings.
各プロンプトに、対応するエコー分野は、文字がタイプされるときユーザ入力がまねられるべきであるかどうかを示します。 クライアントSHOULDは要求メッセージにおける他のプロンプトの如何にかかわらず正しく各プロンプトのためのユーザ入力に反響するか、またはマスクをかけます。 クライアントがいかなる理由でもエコー分野を光栄に思わないなら、クライアントはマスキング入力の側で間違えなければなりません。 GUIクライアントは、チェックボックスにエコー/マスクを切り換えさせるのが好きであるかもしれません。 「クライアントSHOULDは迅速で、そのようなものとしてどんな添字も加えません」: 「(コロンスペース)」。 サーバはユーザに表示するためにすべてのテキストを供給するのに原因となります。 クライアントは、また、ユーザから空の応答を認めて、空のストリングとしてそれらを伝えなければなりません。
Cusack & Forssen Standards Track [Page 6] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[6ページ]。
3.4. Information Responses
3.4. 情報応答
After obtaining the requested information from the user, the client MUST respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message.
ユーザから求められた情報を得た後に、クライアントはSSH_エムエスジー_USERAUTH_INFO_RESPONSEメッセージで応じなければなりません。
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows:
SSH_エムエスジー_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_エムエスジー_USERAUTH_INFO_RESPONSE int num-応答は応答[1](ISO-10646 UTF-8)…ストリング応答[num-応答]を結びます。(ISO-10646 UTF-8)
Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting.
応答がISO-10646 UTF-8でコード化されることに注意してください。 それは応答を解釈して、それらを有効にするサーバまで達しています。 しかしながら、クライアントがある他のコード化(例えば、ISO8859-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パスワードがSHOULDであるとサポートするシステムが、それらがデータベースに追加されるときはいつも、いつもパスワードとユーザ名を正常にするか、またはデータベースでそれら(論じ尽くすことのあるなしにかかわらず)を既存のエントリーと比較します。 それは、パスワードを保存して、それらを比較します。SSH実装、SHOULDは正常化に[SASLPREP]を使用します。
If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message.
num-応答分野が要求メッセージのnum-プロンプト分野に合っていないなら、サーバは失敗メッセージを送らなければなりません。
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-プロンプト野原を送って、クライアントは、交換を終了するために'0'num-応答分野がある応答メッセージを送らなければなりません。
The responses MUST be ordered as the prompts were ordered. That is, response[n] MUST be the answer to prompt[n].
プロンプトが注文されたように命令されて、応答はそうしなければなりません。 すなわち、応答[n]は、[n]をうながすためには答えでなければなりません。
After receiving the response, the server MUST send either an SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message.
応答を受けた後に、サーバは_SSH_エムエスジー_USERAUTH_SUCCESS、SSH_エムエスジーUSERAUTH_FAILUREかSSH_エムエスジー_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
サーバがユーザを認証しない、(基本的な認証機構(s))を通してそれ、SHOULD NOTは新しい認証データを得る試みで別の要求メッセージを送ります。 代わりにそれ、SHOULDは失敗メッセージを送ります。 追加認証データであるなら、サーバが複数の要求メッセージを送るべきである唯一の時間がそうです。
Cusack & Forssen Standards Track [Page 7] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[7ページ]。
is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user).
必要です(すなわち、ユーザを認証するのに使用しなければならない複数の基本的な認証機構があるので)。
If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending it to the client. It is suspected that implementations are likely to make the time delay configurable; a suggested default is 2 seconds.
サーバが失敗メッセージで応じるつもりであるなら、それをクライアントに送る前に、それは実装依存する時間、延着するかもしれません。 実装が時間遅れを構成可能にしそうであると疑われます。 提案されたデフォルトは2秒です。
4. Authentication Examples
4. 認証の例
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)_エムエスジー_USERAUTH_はCを要求します: ストリング、「user23"C:」 「セキュアシェル (SSH)-userauth」Cを結んでください: 「キーボードインタラクティブ」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)_エムエスジー_USERAUTH_インフォメーション_はSを要求します: 「CRYPTOCard認証」Sを結んでください: 「挑戦は'14315716です'」というSを結んでください: 「アン米国」Sを結んでください: int1秒間: ストリング、「応答:」 「S:」 論理演算子TRUE
[Client prompts user for password]
[クライアントはパスワードのためにユーザをうながします]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "6d757575"
C: バイトセキュアシェル (SSH)_エムエスジー_USERAUTH_インフォメーション_応答C: int1C: ストリング"6d757575"
S: byte SSH_MSG_USERAUTH_SUCCESS
S: バイトセキュアシェル (SSH)_エムエスジー_USERAUTH_成功
Cusack & Forssen Standards Track [Page 8] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[8ページ]。
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)_エムエスジー_USERAUTH_はCを要求します: ストリング、「user23"C:」 「セキュアシェル (SSH)-userauth」Cを結んでください: 「キーボードインタラクティブ」Cを結んでください: 「アン米国」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)_エムエスジー_USERAUTH_インフォメーション_はSを要求します: 「パスワード認証」Sを結んでください: ストリング、「「S:」 「アン米国」Sを結んでください: int1秒間: ストリング、「パスワード:」 「S:」 論理演算子FALSE
[Client prompts user for password]
[クライアントはパスワードのためにユーザをうながします]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "password"
C: バイトセキュアシェル (SSH)_エムエスジー_USERAUTH_インフォメーション_応答C: int1C: ストリング「パスワード」
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired."
S: string "en-US"
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
S: バイトセキュアシェル (SSH)_エムエスジー_USERAUTH_インフォメーション_はSを要求します: 「パスワード失効」Sを結んでください: 「あなたのパスワードは吐き出した」ストリング。 S: 「アン米国」Sを結んでください: int2秒間: 「新しいパスワードを入力してください」を結んでください。 「S:」 論理演算子FALSE S: 「もう一度それに入ってください」を結んでください。 「S:」 論理演算子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)_エムエスジー_USERAUTH_インフォメーション_応答C: int2C: "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)_エムエスジー_USERAUTH_インフォメーション_はSを要求します: 「変えられたパスワード」Sを結んでください: 「user23のために首尾よく変えられたパスワード」を結んでください。 S: 「アン米国」Sを結んでください: int0
Cusack & Forssen Standards Track [Page 9] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[9ページ]。
[Client displays message to user]
[クライアントはユーザにメッセージを表示します]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0
C: バイトセキュアシェル (SSH)_エムエスジー_USERAUTH_インフォメーション_応答C: int0
S: byte SSH_MSG_USERAUTH_SUCCESS
S: バイトセキュアシェル (SSH)_エムエスジー_USERAUTH_成功
5. IANA Considerations
5. IANA問題
The userauth type "keyboard-interactive" is used for this authentication method.
userauthタイプ「キーボードインタラクティブ」はこの認証方法に使用されます。
The following method-specific constants are used with this authentication method:
以下のメソッド特有の定数はこの認証方法で使用されます:
SSH_MSG_USERAUTH_INFO_REQUEST 60
SSH_MSG_USERAUTH_INFO_RESPONSE 61
セキュアシェル (SSH)_エムエスジー_USERAUTH_インフォメーション_要求60セキュアシェル (SSH)_エムエスジー_USERAUTH_インフォメーション_応答61
6. Security Considerations
6. セキュリティ問題
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.
このメソッドを使用することで認証を終了するのに必要であるクライアント/サーバ交換の数は可変であるかもしれません。 観察者が単にその数を数えることによって貴重な情報を獲得するのは、可能です。 例えば、観察者は、ユーザのパスワードが期限が切れたと推測して、さらなる観測でサイトのパスワード満了方針で課されたパスワード生涯を決定できるかもしれません。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC-3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC-3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
Cusack & Forssen Standards Track [Page 10] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[10ページ]。
[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-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[セキュアシェル (SSH)-USERAUTH] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))認証プロトコル」、RFC4252、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日
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[SASLPREP]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
7.2. Informative References
7.2. 有益な参照
[PAM] Samar, V., Schemers, R., "Unified Login With
Pluggable Authentication Modules (PAM)", OSF RFC
86.0, October 1995.
[PAM] サマル、V.、策士、R.、「Pluggable認証モジュール(PAM)との統一されたログイン」、OSF RFC86.0、1995年10月。
Authors' Addresses
作者のアドレス
Frank Cusack savecore.net
フランクキューザックsavecore.net
EMail: frank@savecore.net
メール: frank@savecore.net
Martin Forssen AppGate Network Security AB Otterhallegatan 2 SE-411 18 Gothenburg SWEDEN
マーチンForssen AppGateネットワークセキュリティAB Otterhallegatan2SE-411 18イェーテボリスウェーデン
EMail: maf@appgate.com
メール: maf@appgate.com
Cusack & Forssen Standards Track [Page 11] RFC 4256 SSH Generic Interactive Authentication January 2006
キューザックとForssen規格は認証2006年1月にRFC4256セキュアシェル (SSH)ジェネリックインタラクティブを追跡します[11ページ]。
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)によって提供されます。
Cusack & Forssen Standards Track [Page 12]
キューザックとForssen標準化過程[12ページ]
一覧
スポンサーリンク
