Network Working Group J. Galbraith
Request for Comments: 4819 J. Van Dyke
Category: Standards Track VanDyke Software
J. Bright
Silicon Circus
March 2007
Secure Shell Public Key Subsystem
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.
セキュアシェルは、公開鍵に基づいてユーザ認証メカニズムを定義するが、鍵配布のための任意のメカニズムを定義しません。共通鍵管理ソリューションは、現在の実装では存在しません。この文書では、クライアント・ソフトウェアは、この構成の負担を引き受けることができ、実装に依存しない形で、公開鍵を設定するために使用可能なプロトコルを記述します。
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.
クライアントは、公開鍵を追加し、公開鍵を削除し、サーバによって知られている現在の公開鍵を一覧表示するための公開鍵サブシステムは、サーバに依存しないメカニズムを提供します。公開鍵を管理する権利は、特定と認証されたユーザーに限定されています。
A public key may also be associated with various restrictions, including a mandatory command or subsystem.
公開鍵はまた、必須のコマンドまたはサブシステムを含む、様々な制約、関連付けることができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Public Key Subsystem Overview . . . . . . . . . . . . . . . . 3
3.1. Opening the Public Key Subsystem . . . . . . . . . . . . . 4
3.2. Requests and Responses . . . . . . . . . . . . . . . . . . 5
3.3. The Status Message . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 5
3.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 6
4. Public Key Subsystem Operations . . . . . . . . . . . . . . . 7
4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 7
4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 10
4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 10
4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 12
6.2.2. Future Assignments of Names . . . . . . . . . . . . . 13
6.3. Public Key Subsystem Request Names . . . . . . . . . . . . 13
6.4. Public Key Subsystem Response Names . . . . . . . . . . . 13
6.5. Public Key Subsystem Attribute Names . . . . . . . . . . . 13
6.6. Public Key Subsystem Status Codes . . . . . . . . . . . . 14
6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 14
6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 14
6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use.
セキュアシェル（SSH）は、安全でないネットワーク上の安全なリモートログイン及び他の安全なネットワークサービスのためのプロトコルです。セキュアシェルは、公開鍵に基づいてユーザ認証メカニズムを定義するが、鍵配布のための任意のメカニズムを定義しません。一般的な方法は、パスワード認証で一度認証し、サーバに公開鍵を転送することです。しかし、今日まで何の2つの実装が使用する公開鍵を設定するには、同じメカニズムを使用していません。
This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The Public Key Subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a Public Key Infrastructure for X.509 Certificates (PKIX) replacement.
この文書では、実装に依存しない形で、公開鍵を設定するために使用することができ、サブシステムを説明しています。このアプローチは、クライアント・ソフトウェアがこの構成の負担を取ることができます。公開鍵サブシステムのプロトコルが実装における極端な単純化のために設計されています。これは、X.509証明書の公開鍵基盤（PKIX）の代替として意図されていません。
The Secure Shell Public Key Subsystem has been designed to run on top of the Secure Shell transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server.
Secure Shellの公開鍵サブシステムは、セキュア・シェル・トランスポート層の上で動作するように設計されている[2]とユーザ認証プロトコル[3]。これは、クライアントがサーバに公開鍵を管理するためのシンプルなメカニズムを提供します。
This document should be read only after reading the Secure Shell architecture [1] and Secure Shell connection [4] documents.
この文書では、[1]のみのSecure Shellアーキテクチャを読み出した後、およびShell接続[4]の文書を固定する必要があります。
This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey".
節に記載したように、このプロトコルは、「シェルまたはコマンドを起動」、[4]サブシステムとしてセキュアシェル接続プロトコルから使用することが意図されます。このプロトコルで使用されるサブシステム名は「公開鍵」です。
This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added.
このプロトコルは、ユーザーがそれを使用することができます前に、いくつかの方法で認証を行うことができていることが必要です。パスワード認証を使用する場合は第1の公開鍵が追加された後、サーバーは、パスワード認証の使用を無効にする設定オプションを提供する必要があります。
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 [5].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[5]。
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey".
クライアントは、公開鍵を追加し、公開鍵を削除し、サーバによって知られている現在の公開鍵を一覧表示するための公開鍵サブシステムは、サーバに依存しないメカニズムを提供します。サブシステム名は「公開鍵」です。
The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user.
公開鍵は、除去を加え、そしてこのプロトコルを使用して列挙された特定及び認証されたユーザのものに限定されています。
The operations to add, remove, and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data.
追加、削除、および認証されたユーザの公開鍵をリストする操作は、サーバーに送信された要求パケットとして実行されています。サーバーは、成功または失敗を示すだけでなく、特定の応答データを提供し、応答パケットを送信します。
The format of public key blobs are detailed in Section 6.6, "Public Key Algorithms" of the SSH Transport Protocol document [2].
公開鍵ブロブの形式は、[2]、SSHトランスポートプロトコル文書の「公開鍵アルゴリズム」のセクション6.6に詳述されています。
The Public Key Subsystem is started by a client sending an SSH_MSG_CHANNEL_REQUEST over an existing session's channel.
公開鍵サブシステムは、既存のセッションのチャネルを介しSSH_MSG_CHANNEL_REQUESTを送信するクライアントによって開始されます。
The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session".
セッションが開かれている方法の詳細については、SSH接続プロトコル文書に記述されている[4]セクションで、「セッションを開きます」。
To open the Public Key Subsystem, the client sends:
公開鍵サブシステムを開くには、クライアントが送信します。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "subsystem"
boolean want reply
string "publickey"
Client implementations SHOULD reject this request; it is normally sent only by the client.
クライアントの実装は、この要求を拒否すべきです。それは通常のみ、クライアントによって送信されます。
If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the Public Key Subsystem was successfully started, or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the Public Key Subsystem.
返事がTRUEたい場合は、サーバが起動に失敗したか、公開鍵サブシステムをサポートしていない場合、サーバーは、公開鍵サブシステムが正常に起動した場合SSH_MSG_CHANNEL_SUCCESSで応答、またはSSH_MSG_CHANNEL_FAILUREしなければなりません。
The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the Public Key Subsystem (for example, because the user authenticated with a restricted public key).
ユーザーは、公開鍵サブシステムへのアクセスを許可されていない場合（たとえば、ユーザーが制限された公開鍵で認証されたので、）サーバーはSSH_MSG_CHANNEL_FAILUREで応答する必要があります。
It is RECOMMENDED that clients request and check the reply for this request.
クライアントが要求し、この要求に対する応答を確認することをお勧めします。
All Public Key Subsystem requests and responses are sent in the following form:
すべての公開鍵サブシステムの要求と応答は、次の形式で送信されます。
uint32 length
string name
... request/response specific data follows
The length field describes the length of the name field and of the request/response-specific data, but does not include the length of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request.
長さフィールドは、名前フィールドのリクエスト/レスポンス固有のデータの長さを説明するが、長さフィールド自体の長さが含まれていません。クライアントは、前に新しい要求を送信する各リクエストの承認を受けなければなりません。
The version packet, as well as all requests and responses described in Section 4, are a description of the 'name' field and the data part of the packet.
バージョンパケットと同様に、第4章に記載されたすべての要求と応答は、「名前」フィールドの説明と、パケットのデータ部分です。
A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent.
リクエストは、ステータスパケットを送信することで認められています。データが要求に応答してあった場合、すべてのデータが送信された後、ステータスパケットが送信されます。
string "status"
uint32 status code
string description [7]
string language tag [6]
A status message MUST be sent for any unrecognized packets, and the request SHOULD NOT close the subsystem.
ステータスメッセージは、認識されないパケットのために送らなければなりません、との要求は、サブシステムをクローズすべきではありません。
The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values:
ステータスコードは、（ローカライズするのに適した）複数の機械可読形式でのステータスを与え、次の値を有することができます。
SSH_PUBLICKEY_SUCCESS 0
SSH_PUBLICKEY_ACCESS_DENIED 1
SSH_PUBLICKEY_STORAGE_EXCEEDED 2
SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3
SSH_PUBLICKEY_KEY_NOT_FOUND 4
SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5
SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
SSH_PUBLICKEY_GENERAL_FAILURE 7
SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9
If a request completed successfully, the server MUST send the status code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as implied by their names.
要求が正常に完了した場合、サーバはステータスコードSSH_PUBLICKEY_SUCCESSを送らなければなりません。故障コードの意味は、それらの名前によって暗示されます。
Both sides MUST start a connection by sending a version packet that indicates the version of the protocol they are using.
双方は、彼らが使用しているプロトコルのバージョンを示すバージョンパケットを送信して接続を開始しなければなりません。
string "version"
uint32 protocol-version-number
This document describes version 2 of the protocol. Version 1 was used by an early draft of this document. The version number was incremented after changes in the handling of status packets.
このドキュメントでは、プロトコルのバージョン2を説明します。バージョン1は、このドキュメントの初期の草案で使用されていました。バージョン番号は、ステータスパケットの処理中に変化した後インクリメントされました。
Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Note that, normally, status messages are only sent by the server (in response to requests from the client). This is the only occasion on which the client sends a status message.
双方は、彼らが実装する最も高いバージョンを送ります。バージョン番号の下側は、使用するプロトコルのバージョンです。どちらかの側が低いバージョンをサポートできない場合は、サブシステムを閉じてSSH_MSG_CHANNEL_CLOSEメッセージを送信することによって、他の側に通知しなければなりません。サブシステムを閉じる前に、ステータスSSH_PUBLICKEY_VERSION_NOT_SUPPORTEDとステータスメッセージを送ってください。なお、通常は、ステータスメッセージは、のみ（クライアントからの要求に応じて）サーバによって送信されます。これは、クライアントがステータスメッセージを送信するだけの機会です。
Both sides MUST wait to receive this version before continuing. The "version" packet MUST NOT be sent again after this initial exchange. The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent in response to any other request.
双方は、続行する前にこのバージョンを受け取るのを待たなければなりません。 「バージョン」のパケットは、この最初の交換の後に再度送ってはいけません。 SSH_PUBLICKEY_VERSION_NOT_SUPPORTEDステータスコードは、他の要求に応答して送信されてはいけません。
Implementations MAY use the first 15 bytes of the version packet as a "magic cookie" to avoid processing spurious output from the user's shell (as described in Section 6.5 of [4]). These bytes will always be:
（[4]のセクション6.5に記載されているように）実装では、ユーザのシェルからスプリアス出力を処理避けるために、「マジッククッキー」としてバージョンのパケットの最初の15バイトを使用するかもしれません。これらのバイトは、常に次のようになります。
0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E
$ 00 $ 00 $ 00 $ 00 $ 00 0x0Fのは0x00 0x07の0x76 0x65 0x72 0x73 0x69の0x6F 0x6E
The Public Key Subsystem currently defines four operations: add, remove, list, and listattributes.
、リストを追加、削除、およびlistattributes：公開鍵サブシステムは、現在、4つの操作を定義します。
If the client wishes to add a public key, the client sends:
クライアントは、公開鍵を追加したい場合は、クライアントが送信します。
string "add"
string public key algorithm name
string public key blob
boolean overwrite
uint32 attribute-count
string attrib-name
string attrib-value
bool critical
repeated attribute-count times
The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists, but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED.
サーバは、公開鍵は、後続の公開鍵認証のために使用することができるように、適切な場所にユーザの公開鍵を格納しようとしなければなりません。上書きフィールドがfalseで指定したキーがすでに存在する場合、サーバはSSH_PUBLICKEY_KEY_ALREADY_PRESENTを返さなければなりません。サーバーがこれを返した場合、クライアントはキーを上書きするユーザーに選択肢を提供する必要があります。上書きフィールドがtrueであり、指定されたキーがすでに存在するが、上書きすることができない場合は、サーバーはSSH_PUBLICKEY_ACCESS_DENIEDを返さなければなりません。
Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a critical attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a critical attribute, mere storage of the attribute is not sufficient -- rather, the server must understand and implement the intent of the attribute.
属性名は、[1]のアルゴリズム名のためにレイアウト同じスキームに従って定義されます。サーバは、重要な属性を実装していない場合は、ステータスコードSSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTEDで、追加に失敗しなければなりません。重要な属性の目的のためには、属性の単なるストレージが十分ではない - むしろ、サーバーは、属性の意図を理解し、実装する必要があります。
The following attributes are currently defined:
以下の属性は、現在定義されています。
"comment"
"コメント"
The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [7].
コメント属性の値は、公開鍵についてユーザーが指定したテキストが含まれています。サーバはこの値を維持し、それ以降のリスト操作の際にキーとそれを返すためにあらゆる努力をするべきです。サーバが解釈または何らかの方法でコメントフィールドの内容に基づいて行動することを試みてはいけません。コメントの属性はUTF-8形式で指定する必要があります[7]。
The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be critical.
ユーザーがその指紋を比較するに頼ることなく、キーを識別できるように、コメント欄に便利です。この属性は、重要なすべきではありません。
"comment-language"
「コメント言語」
If this attribute is specified, it MUST immediately follow a "comment" attribute and specify the language for that attribute [6]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment with its language attribute. This attribute SHOULD NOT be critical.
この属性が指定されている場合、それはすぐに「コメント」属性に従って、その属性の言語を指定する必要があります[6]。それは、さらに、それらのコメントごとに異なる言語を指定している場合、クライアントは、複数のコメントを指定するかもしれません。サーバーは、その言語属性を持つ各コメントを保存しようとすべきです。この属性は、重要なすべきではありません。
"command-override"
「コマンド・オーバーライド」
"command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorization checks the server may perform). This attribute SHOULD be critical.
「コマンド・オーバーライドは、」このキーが使用されているときに実行するコマンドを指定します。それはそうでない場合は、その要求の結果として実行されていたであろうコマンドやシェルの代わりに、クライアントからの「EXEC」または「シェル」のリクエストを受信したときのコマンドは、サーバで実行する必要があります。コマンド文字列が空の場合は、「EXEC」と「シェル」要求の両方を拒否しなければなりません。何の「コマンド・オーバーライド」属性が指定されていない場合は、すべての「EXEC」と「シェル」の要求が許可されなければならない（限り、彼らは他のセキュリティまたは許可を満たすように、サーバーが実行することをチェック）。この属性は重要であるべきです。
"subsystem"
「サブシステム」
"subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be critical. If the value is empty, no subsystems may be started. If the "subsystem" attribute is not specified, no restrictions are placed on which subsystems may be started when authenticated using this key.
「サブシステム」は、このキーが使用されているときに（「サブシステム」要求を使用して）開始することができるサブシステムのカンマ区切りのリストを指定します。この属性は重要であるべきです。値が空の場合、サブシステムが起動しなくてもよいです。 「サブシステム」属性が指定されていない場合は、何の制限は、認証されたときに、このキーを使用して開始することのできるサブシステムの上に置かれていません。
"x11"
"X11"
"x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical.
「X11」は、このキーが使用されているときにX11フォワーディングが実行されない可能性があることを指定します。属性値フィールドには、この属性の空である必要があります。この属性は重要であるべきです。
"shell"
"シェル"
"shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical.
「シェル」は、このキーが使用されているときにセッションチャンネル「シェル」の要求が拒否されることを指定します。属性値フィールドには、この属性の空である必要があります。この属性は重要であるべきです。
"exec"
「実行」
"exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical.
「幹部は」このキーが使用されているときにセッションチャンネル「幹部」の要求が拒否されることを指定します。属性値フィールドには、この属性の空である必要があります。この属性は重要であるべきです。
"agent"
"エージェント"
"agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical.
「薬剤」は、このキーが使用されているときにセッションチャンネル「のauth-エージェント-REQ」の要求が拒否されることを指定します。属性値フィールドには、この属性の空である必要があります。この属性は重要であるべきです。
"env"
"のEnv"
"env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical.
「envが」このキーが使用されているときにセッションチャンネル「ENV」の要求が拒否されることを指定します。属性値フィールドには、この属性の空である必要があります。この属性は重要であるべきです。
"from"
"から"
"from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorization purposes, the authorization attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. The server should use whatever method is appropriate for its platform to identify the host -- e.g., for IP-based networks, checking the IP address or performing a reverse DNS lookup. For IP-based networks, it is anticipated that each element of the "from" parameter will take the form of a specific IP address or hostname.
キーを使用することができるから、ホストのカンマ区切りリストを指定する「から」。このリストにないホストが認証目的のために、このキーを使用しようとすると、認証の試行は拒否されなければなりません。サーバーは、このに関するログエントリを行う必要があります。サーバーは、管理者はこのリストにホストの外観を禁止するための方法を提供することができます。例えば、IPベースのネットワークのために、IPアドレスをチェックするか、逆DNSルックアップを実行 - サーバーがホストを識別するために、そのプラットフォームに適したどのような方法を使用すべきです。 IPベースのネットワークの場合、「から」パラメータの各要素は、特定のIPアドレスまたはホスト名の形をとることが予想されます。
"port-forward"
「ポートフォワード」
"port-forward" specifies that no "direct-tcpip" requests should be accepted, except those to hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be critical.
「ポート・フォワード」には「直接-TCPIP」要求は、この属性の値として供給されたカンマ区切りのリストで指定されたホストへのものを除いて、受け入れられないことを指定します。この属性の値が空の場合、このキーを使用している場合、すべての「ダイレクト・TCPIP」の要求は拒否されなければなりません。この属性は重要であるべきです。
"reverse-forward"
「リバース・フォワード」
"reverse-forward" specifies that no "tcpip-forward" requests should be accepted, except for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be critical.
「リバース・フォワード」なし「TCPIPフォワード」の要求は、この属性の値として供給されたカンマ区切りリストでポート番号を除いて、受け入れられないことを指定します。この属性の値が空の場合、このキーを使用している場合、すべての「TCPIPフォワード」の要求は拒否されなければなりません。この属性は重要であるべきです。
In addition to the attributes specified by the client, the server MAY provide a method for administrators to enforce certain attributes compulsorily.
クライアントによって指定された属性に加えて、サーバは、管理者が強制的に特定の属性を強制するための方法を提供することができます。
If the client wishes to remove a public key, the client sends:
クライアントは、公開鍵を削除したい場合は、クライアントが送信します。
string "remove"
string public key algorithm name
string public key blob
The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications.
サーバは、公開鍵は、後続の認証のために使用することができないように、適切な場所からユーザの公開鍵を削除しようとしなければなりません。
If the client wishes to list the known public keys, the client sends:
クライアントが知られている公開鍵の一覧を表示したい場合は、クライアントが送信します。
string "list"
文字列「リスト」
The server will respond with zero or more of the following responses:
サーバーは次の応答のゼロ以上で応答します。
string "publickey"
string public key algorithm name
string public key blob
uint32 attribute-count
string attrib-name
string attrib-value
repeated attribute-count times
There is no requirement that the responses be in any particular order. Whilst some server implementations may send the responses in some order, client implementations should not rely on responses being in any order.
応答は、特定の順序である必要はありません。一部のサーバーの実装は、いくつかのために応答を送信するかもしれないが、クライアントの実装は、任意の順序であること応答に依存しないでください。
Following the last "publickey" response, a status packet MUST be sent.
最後の「公開」応答に続いて、ステータスパケットを送らなければなりません。
Implementations SHOULD support this request.
実装は、この要求をサポートする必要があります。
If the client wishes to know which key attributes the server supports, it sends:
クライアントは、サーバーがサポートする属性をキー知りたい場合は、それが送信されます。
string "listattributes"
文字列「listattributes」
The server will respond with zero or more of the following responses:
サーバーは次の応答のゼロ以上で応答します。
string "attribute"
string attribute name
boolean compulsory
The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. An example of use of the "compulsory" attribute would be a server with a configuration file specifying that the user is not permitted shell access. Given this, the server would return the "shell" attribute, with "compulsory" marked true. Whatever attributes the user subsequently asked the server to apply to their key, the server would also apply the "shell" attribute, rendering it impossible for the user to use a shell.
「強制」フィールドには、この属性が強制的に起因するサーバーの管理者の設定に任意の追加のキー（関係なく、属性がクライアントによって指定されているかどうかの）に適用されるかどうかを示します。サーバは、この自然の管理設定をサポートしていない場合は、強制的なフィールドにfalseを返さなければなりません。 「強制」属性の使用例は、ユーザーがシェルアクセスを許可されていないことを指定する構成ファイルを使用してサーバーになります。この与えられた、サーバーは真のマーク「強制」で、「シェル」属性を返します。どのようなユーザーが、その後自分のキーに適用するには、サーバーを頼ま属性、またそれは不可能ユーザーがシェルを使用するためのレンダリング、「シェル」属性を適用するサーバー。
Following the last "attribute" response, a status packet MUST be sent.
最後の「属性」応答に続いて、ステータスパケットを送らなければなりません。
An implementation MAY choose not to support this request.
実装は、この要求をサポートしないこともできます。
This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks.
このプロトコルは、それが安全なチャネルを介して、チャンネルのエンドポイントが認証されていることを実行していることを前提としています。したがって、このプロトコルは、それが外部からのネットワークレベルの攻撃から保護されていることを前提としています。
This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator.
このプロトコルは、クライアントの認証データをアップロードして操作することを可能にするメカニズムを提供します。 （典型的には、SSHユーザ認証プロトコルを使用して、このプロトコルに外部認証されたユーザ、[3]）は、任意の特定のユーザに許可されるアクセスを制限するために必要とされ得る任意のアクセス制御を強制するサーバの実装の責任です。ユーザーが同時に以前に存在していたよりも、新しいキーのための少数の制限を指定しながら、このプロトコルを使用してサーバー上の既存のキーを上書きするため、特に、それが可能です。サーバはこれを行う際に、クライアントはサーバーの管理者からのプリセットを上書きすることができないことに注意する必要があります。
This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorize keys for access they were not intended to have, or to apply fewer restrictions than were intended.
このプロトコルは、サーバーが正しく実装し、キーに適用される属性を遵守することを前提とするクライアントが必要です。サーバーで実装エラーは、彼らが持っている、または意図していたよりも少ない制限を適用することを意図していなかったアクセスのためのキーを許可するクライアントを引き起こす可能性があります。
This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments.
このセクションでは、名前空間の命名に使用される規則、レジストリの初期状態、および将来の割り当てのための命令が含まれています。
Consistent with Section 4.9.5 of [8], this document makes the following registration:
[8]のセクション4.9.5と一致して、このドキュメントは以下の登録を行います。
The subsystem name "publickey".
サブシステム名「公開鍵」。
In the following sections, the values for the namespaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections.
次のセクションでは、名前空間の値はテキスト形式です。将来の割り当てのためのIANAへの規則および手順は、このセクションに記載されています。最初の割り当ては、それぞれのセクションに記載されています。
All names registered by the IANA in the following sections MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ("@"), comma (","), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters.
次のセクションでIANAによって登録されたすべての名前が印刷可能なUS-ASCII文字列でなければならない、とアットマーク（「@」）、コンマ文字を含めることはできません（「」）、または空白や制御文字（ASCIIコード32またはもっと少なく）。名前は大文字と小文字が区別され、64文字以上にすることはできません。
A provision is made here for locally extensible names. The IANA will not register and will not control names with the at-sign in them. Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceding the at-sign is the name. The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), or whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified Internet domain name [10] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [9] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [9]. An example of a locally defined name is "our-attribute@example.com" (without the double quotes).
引当金は、局部的に拡張可能な名前のためにここで行われています。 IANAは登録されませんし、その中のアットマークで名前をコントロールしません。その中で、符号付きの名前はアットマークの前の部分が名前である（二重引用符なし）「名@ドメイン名」の形式を持っています。アットマークの前部分のフォーマットが指定されていません。しかし、これらの名前は、印刷可能なUS-ASCII文字列でなければならない、とコンマ文字（「」）、または空白、または制御文字（ASCIIコード32以下）を含めることはできません。アットマークを以下の部分は、有効な、完全修飾インターネットドメイン名の名前を定義する個人または組織によって制御される[10]でなければなりません。名前は大文字と小文字が区別され、64文字以上にすることはできません。それはそのローカル名前空間をどのように管理するか、各ドメインに任されています。これらの名前は、STD 11 [9]のメールアドレスに似ていることが指摘されています。これは純粋な偶然で、実際STD 11 [9]とは何の関係もありません。ローカルに定義された名前の例としては、（二重引用符なし）「our-attribute@example.com」です。
Requests for assignments of new Names MUST be done through the IETF Consensus method as described in [11].
[11]に記載されているように、新しい名前の割り当ての要求は、IETFコンセンサス方法を介して行われなければなりません。
The following table lists the initial assignments of Public Key Subsystem Request names.
次の表は、公開鍵サブシステム要求の名前の最初の割り当てを示します。
Request Name
-------------
version
add
remove
list
listattributes
The following table lists the initial assignments of Public Key Subsystem Response names.
次の表は、公開鍵サブシステムのレスポンスの名前の最初の割り当てを示します。
Response Name
--------------
version
status
publickey
attribute
Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Public Key Subsystem Attribute names.
属性は、公開鍵のプロパティまたは制限を定義するために使用されています。次の表は、公開鍵サブシステムの初期割り当ては、属性名は一覧表示されます。
Attribute Name
---------------
comment
comment-language
command-override
subsystem
x11
shell
exec
agent
env
from
port-forward
reverse-forward
The status code is a byte value, describing the status of a request.
ステータスコードは、リクエストのステータスを記述し、バイト値です。
Status responses have status codes in the range 0 to 255. These numbers are allocated as follows. Of these, the range 192 to 255 is reserved for use by local, private extensions.
ステータス応答は次のように0〜255これらの番号が割り当てられている範囲内のステータスコードを持っています。このうち、255の範囲192は、ローカル、プライベート拡張で使用するために予約されています。
The following table identifies the initial assignments of the Public Key Subsystem status code values.
次の表は、公開鍵サブシステムのステータスコード値の初期割り当てを識別します。
Status code Value Reference
------------ ----- ---------
SSH_PUBLICKEY_SUCCESS 0
SSH_PUBLICKEY_ACCESS_DENIED 1
SSH_PUBLICKEY_STORAGE_EXCEEDED 2
SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3
SSH_PUBLICKEY_KEY_NOT_FOUND 4
SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5
SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
SSH_PUBLICKEY_GENERAL_FAILURE 7
SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9
Requests for assignments of new status codes in the range of 0 to 191 MUST be done through the Standards Action method as described in [11].
[11]に記載のように0〜191の範囲内の新たなステータスコードの割り当ての要求は、標準処置方法を介して行われなければなりません。
The IANA will not control the status code range of 192 through 255. This range is for private use.
IANAは、この範囲は、私的使用のためである255を通じて192のステータスコードの範囲を制御しません。
[1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[1] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[2] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）トランスポート層プロトコル"、RFC 4253、2006年1月。
[3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[3] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）認証プロトコル"、RFC 4252、2006年1月。
[4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[4] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）接続プロトコル"、RFC 4254、2006年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[6]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 4646、2006年9月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[8] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[8]レーティネン、S.とC. Lonvick、 "セキュアシェル（SSH）プロトコル割り当て番号"、RFC 4250、2006年1月。
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[9]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[10] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[10] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[11] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
Brent McClure contributed to the writing of this document.
ブレントマクルーアは、本書の執筆に貢献しました。
Authors' Addresses
著者のアドレス
Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US
ジョセフ・ガルブレイスバンダイクソフトウェア4848路面電車リッジブルバードスイート101アルバカーキ、NM 87111米国
Phone: +1 505 332 5700 EMail: galb@vandyke.com
電話：+1 505 332 5700 Eメール：galb@vandyke.com
Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US
ジェフ・P.ヴァン・ダイクバンダイクソフトウェア4848路面電車リッジブルバードスイート101アルバカーキ、NM 87111米国
Phone: +1 505 332 5700 EMail: jpv@vandyke.com
電話：+1 505 332 5700 Eメール：jpv@vandyke.com
Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK
ジョン明るいシリコンサーカス24ジュビリー道チチェスター、ウエストサセックスPO19 7XB英国
Phone: +49 172 524 0521 EMail: jon@siliconcircus.com
電話：+49 172 524 0521 Eメール：jon@siliconcircus.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。