[要約] RFC 4819は、SSHの公開鍵サブシステムに関する仕様であり、公開鍵認証のためのプロトコルを定義しています。その目的は、セキュアなリモートアクセスやファイル転送を可能にするため、SSHの公開鍵認証の仕組みを提供することです。
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）The IETF Trust（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.
Secure Shellは、パブリックキーに基づいたユーザー認証メカニズムを定義しますが、キーディストリビューションのメカニズムを定義しません。現在の実装には一般的なキー管理ソリューションは存在しません。このドキュメントでは、実装に依存しない方法でパブリックキーを構成するために使用できるプロトコルについて説明し、クライアントソフトウェアがこの構成の負担を引き受けることができます。
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.
Secure Shell（SSH）は、安全でないネットワークを介した安全なリモートログインおよびその他の安全なネットワークサービスのプロトコルです。Secure Shellは、パブリックキーに基づいたユーザー認証メカニズムを定義しますが、キーディストリビューションのメカニズムを定義しません。一般的な慣行は、パスワード認証で一度認証し、公開キーをサーバーに転送することです。ただし、現在までに、同じメカニズムを使用して使用する公開キーを構成する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.
安全なシェル公開キーサブシステムは、安全なシェル輸送層[2]およびユーザー認証プロトコル[3]の上で実行されるように設計されています。クライアントがサーバー上のパブリックキーを管理する簡単なメカニズムを提供します。
This document should be read only after reading the Secure Shell architecture [1] and Secure Shell connection [4] documents.
このドキュメントは、安全なシェルアーキテクチャ[1]とセキュアシェル接続[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]からサブシステムとして使用することを目的としています。このプロトコルで使用されるサブシステム名は「publicKey」です。
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.
このプロトコルでは、ユーザーが使用する前に何らかの方法で認証できる必要があります。パスワード認証が使用されている場合、サーバーは、最初の公開キーが追加された後にパスワード認証の使用を無効にする構成オプションを提供する必要があります。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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".
公開キーサブシステムは、クライアントがパブリックキーを追加し、パブリックキーを削除し、サーバーが知っている現在のパブリックキーをリストするためのサーバーに依存しないメカニズムを提供します。サブシステム名は「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].
公開キーブロブの形式は、SSH輸送プロトコルドキュメントのセクション6.6「公開キーアルゴリズム」[2]で詳しく説明されています。
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"
BYTE SSH_MSG_CHANNEL_REQUEST UINT32レシピエントチャネル文字
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.
返信が必要な場合は、サーバーが正常に開始された場合、サーバーはSSH_MSG_CHANNEL_SUCCESSで応答する必要があります。
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
uint32長さの文字列名...リクエスト/応答特定のデータが続きます
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]
文字列「ステータス」UINT32ステータスコード文字列説明[7]文字列言語タグ[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
文字列「バージョン」UINT32プロトコルバージョン番号
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:
実装は、バージョンパケットの最初の15バイトを「マジッククッキー」として使用して、ユーザーのシェルからのスプリアス出力を処理しないようにする場合があります（[4]のセクション6.5で説明されています）。これらのバイトは常に次のとおりです。
0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E
0x00 0x00 0x00 0x0f 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6f 0x6e
The Public Key Subsystem currently defines four operations: add, remove, list, and 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
文字列「追加」文字列公開キーアルゴリズム名名String pobly key blob boolean overwrite uint32属性 - 文字列attrib-name string attrib-value bool crital repeated repeated 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_aledy_pready_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を使用して、addを失敗させる必要があります。重要な属性の目的のために、属性の単なるストレージでは十分ではありません。むしろ、サーバーは属性の意図を理解して実装する必要があります。
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」と「shell」要求の両方を拒否する必要があります。「コマンドオーバーライド」属性が指定されていない場合、すべての「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」
"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.
「exec」は、このキーが使用されているときにセッションチャネル「exec」要求を拒否する必要があることを指定します。この属性の属性値フィールドは空にする必要があります。この属性は重要である必要があります。
"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-Agent-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.
「From」は、キーを使用できるホストのコンマ分離されたリストを指定します。このリストにないホストが承認目的でこのキーを使用しようとする場合、承認の試みは拒否されなければなりません。サーバーは、これに関してログエントリを作成する必要があります。サーバーは、管理者がこのリストのホストの外観を許可する方法を提供する場合があります。サーバーは、ホストを識別するためにプラットフォームに適した方法を使用する必要があります。たとえば、IPベースのネットワークの場合、IPアドレスのチェック、または逆DNSルックアップの実行。IPベースのネットワークの場合、「From」パラメーターの各要素は、特定の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-Forward」リクエストは受け付けないことを指定します。この属性の値が空の場合、このキーを使用する場合、すべての「tcpip-forward」要求は拒否されるべきです。この属性は重要である必要があります。
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
文字列「publickey」文字列公開キーアルゴリズム名String poblyキーBlob Uint32属性 - 文字列属性 - value repeated属性 - カウント時間
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.
最後の「publicKey」応答に続いて、ステータスパケットを送信する必要があります。
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
文字列「属性」文字列属性名Boolean Compurertory
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]を使用して、このプロトコルに外部から認証されるアクセスを制限するために必要なアクセスコントロールを実施することは、サーバー実装の責任です[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".
サブシステム名「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文字列でなければならず、文字がait-Sign（ "@"）、comma（ "、"）、またはwhitespaceまたはcontrol文字を含めてはなりません（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は登録せず、At-Signの名前を制御しません。AT-SIGNが含まれている名前には、「name@domainname」（二重引用符なし）の形式があり、ait-signの前の部分が名前です。AT-SIGNの前の部品の形式は指定されていません。ただし、これらの名前は印刷可能なUS-ASCII文字列でなければならず、コンマ文字（ "、"）、またはWhitespace、またはコントロール文字（ASCIIコード32以下）を含めてはなりません。AT-Signに続く部分は、名前を定義する人または組織によって制御される有効で完全に適格なインターネットドメイン名[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の範囲のステータスコードがあります。これらの数値は次のように割り当てられます。これらのうち、192〜255の範囲は、ローカルのプライベートエクステンションで使用するために予約されています。
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].
0〜191の範囲での新しいステータスコードの割り当てのリクエストは、[11]で説明されている標準アクションメソッドを通じて行う必要があります。
The IANA will not control the status code range of 192 through 255. This range is for private use.
IANAは、192〜255のステータスコード範囲を制御しません。この範囲はプライベート使用用です。
[1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[1] Ylonen、T。およびC. Lonvick、「The Secure Shell（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、「The Secure Shell（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、「The Secure Shell（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、「The Secure Shell（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[6] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、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] Lehtinen、S。およびC. Lonvick、「The Secure Shell（SSH）プロトコルが割り当てられた数字」、RFC 4250、2006年1月。
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[9] Crocker、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.
[11] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Brent McClure contributed to the writing of this document.
Brent McClureは、この文書の執筆に貢献しました。
Authors' Addresses
著者のアドレス
Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US
Joseph Galbraith Vandyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque、NM 87111 US
Phone: +1 505 332 5700
EMail: galb@vandyke.com
Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US
Jeff P. Van Dyke Vandyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque、NM 87111 US
Phone: +1 505 332 5700
EMail: jpv@vandyke.com
Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK
ジョンブライトシリコンサーカス24ジュビリーロードチチェスター、ウェストサセックスPO19 7xb UK
Phone: +49 172 524 0521
EMail: jon@siliconcircus.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。