[要約] RFC 9987は、SSHクライアントと秘密鍵を保持するバックグラウンドプロセス（ssh-agent等）との通信を標準化するプロトコルを規定した文書です。鍵の登録や削除、秘密鍵の露出を防ぐ署名要求、エージェントフォワーディングといった各種機能・要件を定義しています。
Internet Engineering Task Force (IETF) D. Miller
Request for Comments: 9987 OpenSSH
Category: Standards Track May 2026
ISSN: 2070-1721
This document specifies a key agent protocol for use in the Secure Shell (SSH) protocol.
この文書では、セキュア シェル (SSH) プロトコルで使用するキー エージェント プロトコルを指定します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9987.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9987 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Requirements Language
3. Protocol Overview
4. Terminology and Units
5. Protocol Messages
5.1. Generic Agent Responses
5.2. Adding Keys to the Agent
5.2.1. DSA Keys
5.2.2. ECDSA Keys
5.2.3. EdDSA Keys
5.2.4. RSA Keys
5.2.5. Other Keys
5.2.6. Adding Keys from a Token
5.2.7. Key Constraints
5.3. Public Key Encoding
5.4. Removing Keys from the Agent
5.5. Requesting a List of Keys
5.6. Private Key Operations
5.6.1. Signature Flags
5.7. Locking and Unlocking an Agent
5.8. Extension Mechanism
5.8.1. Query Extension
6. Connecting to an Agent
7. Forwarding Access to an Agent
7.1. Advertising Agent Forwarding Support
7.2. Requesting Agent Forwarding
7.3. Agent Connection Requests
8. Protocol Numbers
8.1. Message Type Numbers
8.1.1. Reserved Message Type Numbers
8.2. Constraint Identifiers
8.3. Signature Flags
9. IANA Considerations
9.1. Guidance for Designated Experts
9.2. "SSH Agent Protocol Message Type Numbers" Registry
9.3. "SSH Agent Key Constraint Numbers" Registry
9.4. "SSH Agent Key Constraint Extension Names" Registry
9.5. "SSH Agent Signature Flags" Registry
9.6. "SSH Agent Extension Request Names" Registry
9.7. Additions to the "Extension Names" Registry
9.8. Additions to the "Connection Protocol Channel Request
Names" Registry
9.9. Additions to the "Connection Protocol Channel Types"
Registry
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Author's Address
Secure Shell (SSH) [RFC4251] is a protocol for secure remote connections [RFC4253] and login [RFC4254] over untrusted networks. It supports multiple authentication mechanisms [RFC4252] including public key authentication. This document specifies the protocol for interacting with a key management component, usually referred to as "an agent", that holds private keys. SSH clients (and possibly SSH servers) can invoke the agent via this protocol to perform operations using public and private keys held in the agent.
Secure Shell (SSH) [RFC4251] は、信頼できないネットワーク上での安全なリモート接続 [RFC4253] およびログイン [RFC4254] のためのプロトコルです。公開鍵認証を含む複数の認証メカニズム [RFC4252] をサポートします。この文書は、秘密鍵を保持する鍵管理コンポーネント (通常は「エージェント」と呼ばれる) と対話するためのプロトコルを指定します。SSH クライアント (場合によっては SSH サーバー) は、このプロトコル経由でエージェントを呼び出し、エージェントに保持されている公開鍵と秘密鍵を使用して操作を実行できます。
Holding keys in an agent offers usability and security advantages to loading and unwrapping them at each use, as each key unwrapping may require entry of a passphrase. Access to an agent may optionally be forwarded across an SSH connection, thereby allowing remote systems to use stored keys without directly exposing the key material to the remote system. Finally, the agent may be implemented as a dedicated component that presents a smaller attack surface than a key loaded into a full SSH server or client and that may be subject to special protection from the wider system.
エージェントでキーを保持すると、キーのラップを解除するたびにパスフレーズの入力が必要になる場合があるため、使用するたびにキーをロードおよびラップ解除することが容易になり、セキュリティ上の利点が得られます。オプションでエージェントへのアクセスを SSH 接続経由で転送することで、リモート システムがキー マテリアルを直接公開することなく、保存されているキーを使用できるようになります。最後に、エージェントは、完全な SSH サーバーまたはクライアントにロードされたキーよりも攻撃対象領域が小さく、より広範なシステムからの特別な保護の対象となる専用コンポーネントとして実装できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The agent protocol is a packetised request-response protocol that is solely driven by the client. It consists of a number of requests sent from a client to an agent and a set of reply messages that are sent in response. At no time does the agent send messages except in response to a client request. Replies are sent in order.
エージェント プロトコルは、クライアントによってのみ駆動されるパケット化された要求/応答プロトコルです。これは、クライアントからエージェントに送信される多数のリクエストと、それに応じて送信される一連の応答メッセージで構成されます。クライアントの要求に応答する場合を除き、エージェントはメッセージを送信しません。返信は順番に送信されます。
These requests include the ability to load keys into an agent, remove some or all keys from an agent, and perform signature operations using previously loaded keys.
これらのリクエストには、エージェントにキーをロードする機能、エージェントから一部またはすべてのキーを削除する機能、および以前にロードされたキーを使用して署名操作を実行する機能が含まれます。
Agents MAY implement support for only a subset of available key types and MAY additionally refuse some operations in particular contexts. For example, an agent may allow only clients local to itself to add keys or may make particular subsets of keys available to a given client. For this reason, clients of the agent SHOULD be prepared to fail gracefully if any operation is refused.
エージェントは、利用可能なキータイプのサブセットのみのサポートを実装してもよく、さらに特定のコンテキストで一部の操作を拒否してもよいです。たとえば、エージェントは、それ自体にローカルなクライアントのみにキーの追加を許可したり、キーの特定のサブセットを特定のクライアントが利用できるようにしたりできます。このため、エージェントのクライアントは、操作が拒否された場合に正常に失敗するように準備する必要があります (SHOULD)。
Henceforth, in this document, "agent" will be used to refer to a key management component that implements the responder side of this protocol. "Client" will refer to a tool that implements the requester side of the protocol to communicate with an agent. If it is pertinent that the client in question is a Secure Shell client as described in [RFC4251], then the client will be explicitly referred to as an "SSH client". Similarly, "SSH server" will be used to refer to Secure Shell servers.
以降、この文書では、このプロトコルのレスポンダー側を実装するキー管理コンポーネントを指すために「エージェント」を使用します。「クライアント」とは、エージェントと通信するためにプロトコルのリクエスター側を実装するツールを指します。[RFC4251] で説明されているように、問題のクライアントが Secure Shell クライアントであることが適切な場合、クライアントは明示的に「SSH クライアント」と呼ばれます。同様に、「SSH サーバー」は Secure Shell サーバーを指すために使用されます。
All encoding data types ("byte", "uint32", "string", etc.) are as specified in Section 5 of [RFC4251]. Additionally, the type "byte[]" without a specified length within the square brackets indicates an unadorned sequence of zero or more bytes where the length is determined by context.
すべてのエンコーディング データ型 (「byte」、「uint32」、「string」など) は、[RFC4251] のセクション 5 で指定されているとおりです。さらに、角括弧内に長さが指定されていないタイプ「byte[]」は、長さがコンテキストによって決定される、装飾のない 0 バイト以上のシーケンスを示します。
All length units are given in bytes unless otherwise specified.
特に指定しない限り、長さの単位はすべてバイト単位で示されます。
Messages consist of a "length", "type", and "contents".
メッセージは「長さ」「種類」「内容」で構成されます。
uint32 length
byte type
byte[length - 1] contents
In the sections below, the "length" field is omitted. For clarity, the symbolic names of the message types are shown; their numeric values are listed in Section 8.1.
以下のセクションでは、「長さ」フィールドは省略されています。わかりやすくするために、メッセージ タイプのシンボル名が示されています。それらの数値はセクション 8.1 にリストされています。
The following generic messages may be sent by the agent in response to requests from the client. On success, the agent MUST reply either with the single-byte response:
次の一般的なメッセージは、クライアントからの要求に応じてエージェントによって送信される場合があります。成功した場合、エージェントは次のいずれかのシングルバイト応答で応答しなければなりません。
byte SSH_AGENT_SUCCESS
or with a request-specific success message that may contain additional fields. On failure, the agent MUST reply with the single-byte response:
または、追加のフィールドが含まれる可能性があるリクエスト固有の成功メッセージを使用します。失敗した場合、エージェントは次のシングルバイト応答で応答しなければなりません。
byte SSH_AGENT_FAILURE
or with a request-specific failure message that may contain additional fields. SSH_AGENT_FAILURE messages MUST also be sent in reply to requests with unknown or unsupported types.
または、追加のフィールドが含まれる可能性があるリクエスト固有の失敗メッセージを使用します。SSH_AGENT_FAILURE メッセージは、不明なタイプまたはサポートされていないタイプのリクエストへの応答としても送信されなければなりません (MUST)。
Keys may be added to the agent using the SSH_AGENTC_ADD_IDENTITY or SSH_AGENTC_ADD_ID_CONSTRAINED messages. The latter variant allows adding keys with optional constraints on their usage.
キーは、SSH_AGENTC_ADD_IDENTITY または SSH_AGENTC_ADD_ID_CONSTRAINED メッセージを使用してエージェントに追加できます。後者のバリアントでは、使用法にオプションの制約を付けてキーを追加できます。
The generic format for the SSH_AGENTC_ADD_IDENTITY message is:
SSH_AGENTC_ADD_IDENTITY メッセージの一般的な形式は次のとおりです。
byte SSH_AGENTC_ADD_IDENTITY
string key type
byte[] key data
string comment
Here "key type" is the specified key type name, for example, "ssh-rsa" for an RSA key as defined by [RFC4253]. The "key data" consists of the public and private components of the key and varies by key type, as specified in Sections 5.2.1 through 5.2.4 for commonly used key types. A "comment" is a human-readable key name or comment as a UTF-8 string that may serve to identify the key in user-visible messages. This string may be of zero length.
ここで、「key type」は指定された鍵タイプの名前です。たとえば、[RFC4253] で定義されている RSA 鍵の場合は「ssh-rsa」です。「鍵データ」は、鍵の公開コンポーネントと秘密コンポーネントで構成され、一般的に使用される鍵タイプについてセクション 5.2.1 から 5.2.4 で指定されているように、鍵タイプによって異なります。「コメント」は、人間が読めるキー名または UTF-8 文字列としてのコメントで、ユーザーに表示されるメッセージ内でキーを識別するのに役立ちます。この文字列の長さはゼロである可能性があります。
The SSH_AGENTC_ADD_ID_CONSTRAINED message is similar but adds an extra field:
SSH_AGENTC_ADD_ID_CONSTRAINED メッセージは似ていますが、追加のフィールドが追加されています。
byte SSH_AGENTC_ADD_ID_CONSTRAINED
string key type
byte[] key data
string comment
constraint[] constraints
Constraints are used to place limits on the validity or use of keys. Section 5.2.7 details constraint types and their formats. Clients SHOULD prefer the SSH_AGENTC_ADD_IDENTITY message over sending an SSH_AGENTC_ADD_ID_CONSTRAINED message with an empty "constraints" field, though both are valid and equivalent.
制約は、キーの有効性または使用に制限を設けるために使用されます。セクション 5.2.7 では、制約タイプとその形式について詳しく説明します。クライアントは、空の「制約」フィールドを含む SSH_AGENTC_ADD_ID_CONSTRAINED メッセージを送信するよりも、SSH_AGENTC_ADD_IDENTITY メッセージを優先すべきです (ただし、どちらも有効で同等です)。
An agent MUST reply with SSH_AGENT_SUCCESS if the key was successfully loaded as a result of one of these messages or SSH_AGENT_FAILURE otherwise.
エージェントは、これらのメッセージのいずれかの結果としてキーが正常にロードされた場合は SSH_AGENT_SUCCESS で応答し、それ以外の場合は SSH_AGENT_FAILURE で応答しなければなりません (MUST)。
Adding a key that is already present in an agent SHOULD replace any constraints it was previously loaded with those (if any) that are present in the subsequent add request, as this ensures that security-relevant constraints on a loaded key best match user expectations. Otherwise, an agent MAY refuse to load a key that has already been loaded.
エージェントにすでに存在するキーを追加する場合は、以前にロードされた制約を、後続の追加リクエストに存在する制約 (存在する場合) で置き換えるべきです (SHOULD)。これにより、ロードされたキーに対するセキュリティ関連の制約がユーザーの期待に最もよく一致することが保証されます。それ以外の場合、エージェントは、すでにロードされているキーのロードを拒否してもよい(MAY)。
An agent MAY support only a subset of the key types defined here and MAY support additional key types as described below. If an agent does not recognise the type name in a request to add a key, then it MUST respond with an SSH_AGENT_FAILURE reply.
エージェントは、ここで定義されたキー タイプのサブセットのみをサポートしてもよく、以下で説明する追加のキー タイプをサポートしてもよいです。エージェントがキー追加リクエストのタイプ名を認識しない場合、SSH_AGENT_FAILURE 応答で応答しなければなりません (MUST)。
Digital Signature Algorithm (DSA) keys have key type name "ssh-dss" and are defined in [RFC4253]. They may be added to the agent using the following message. The "constraints" field is only present for the SSH_AGENTC_ADD_ID_CONSTRAINED message.
デジタル署名アルゴリズム (DSA) 鍵は、鍵タイプ名「ssh-dss」を持ち、[RFC4253] で定義されています。これらは、次のメッセージを使用してエージェントに追加できます。「constraints」フィールドは、SSH_AGENTC_ADD_ID_CONSTRAINED メッセージにのみ存在します。
byte SSH_AGENTC_ADD_IDENTITY or
SSH_AGENTC_ADD_ID_CONSTRAINED
string "ssh-dss"
mpint p
mpint q
mpint g
mpint y
mpint x
string comment
constraint[] constraints
The "p", "q", and "g" values are the DSA domain parameters. The "y" and "x" values are the public and private keys, respectively. These values are as defined by Section 4.1 of [FIPS.186-4].
「p」、「q」、および「g」の値は、DSA ドメイン パラメーターです。「y」と「x」の値は、それぞれ公開鍵と秘密鍵です。これらの値は、[FIPS.186-4] のセクション 4.1 で定義されているとおりです。
Elliptic Curve Digital Signature Algorithm (ECDSA) keys have key types starting with "ecdsa-sha2-" and are defined in [RFC5656]. They may be added to the agent using the following message. The "constraints" field is only present for the SSH_AGENTC_ADD_ID_CONSTRAINED message.
楕円曲線デジタル署名アルゴリズム (ECDSA) 鍵には、「ecdsa-sha2-」で始まる鍵タイプがあり、[RFC5656] で定義されています。これらは、次のメッセージを使用してエージェントに追加できます。「constraints」フィールドは、SSH_AGENTC_ADD_ID_CONSTRAINED メッセージにのみ存在します。
byte SSH_AGENTC_ADD_IDENTITY or
SSH_AGENTC_ADD_ID_CONSTRAINED
string key type
string ecdsa_curve_name
string Q
mpint d
string comment
constraint[] constraints
The values "Q" and "d" are the ECDSA public and private values respectively. Both are defined by Section 6.2 of [FIPS.186-5].
値「Q」と「d」は、それぞれ ECDSA のパブリック値とプライベート値です。両方とも [FIPS.186-5] のセクション 6.2 で定義されています。
[RFC8709] defines Edwards-curve Digital Signature Algorithm (EdDSA) keys (see [RFC8032]) Ed25519 and Ed448 with key type names "ssh-ed25519" and "ssh-ed448", respectively. These may be added to the agent using the following message. The "constraints" field is only present for the SSH_AGENTC_ADD_ID_CONSTRAINED message.
[RFC8709] は、エドワーズ曲線デジタル署名アルゴリズム (EdDSA) 鍵 ([RFC8032] を参照) Ed25519 および Ed448 を、それぞれ鍵タイプ名「ssh-ed25519」および「ssh-ed448」で定義します。これらは、次のメッセージを使用してエージェントに追加できます。「constraints」フィールドは、SSH_AGENTC_ADD_ID_CONSTRAINED メッセージにのみ存在します。
byte SSH_AGENTC_ADD_IDENTITY or
SSH_AGENTC_ADD_ID_CONSTRAINED
string "ssh-ed25519" or "ssh-ed448"
string ENC(A)
string k || ENC(A)
string comment
constraint[] constraints
The first value is the EdDSA public key ENC(A). The second value is a concatenation of the private key k and the public ENC(A) key (this repetition of the public key is to maintain compatibility with widely deployed implementations). The contents and interpretation of the ENC(A) and k values are defined by Section 3.2 of [RFC8032].
最初の値は EdDSA 公開キー ENC(A) です。2 番目の値は、秘密キー k と公開 ENC(A) キーを連結したものです (公開キーのこの繰り返しは、広く導入されている実装との互換性を維持するためです)。ENC(A) および k 値の内容と解釈は、[RFC8032] のセクション 3.2 で定義されています。
RSA keys have key type name "ssh-rsa" and are defined in [RFC4253]. They may be added to the agent using the following message. The "constraints" field is only present for the SSH_AGENTC_ADD_ID_CONSTRAINED message.
RSA 鍵は鍵タイプ名「ssh-rsa」を持ち、[RFC4253] で定義されています。これらは、次のメッセージを使用してエージェントに追加できます。「constraints」フィールドは、SSH_AGENTC_ADD_ID_CONSTRAINED メッセージにのみ存在します。
byte SSH_AGENTC_ADD_IDENTITY or
SSH_AGENTC_ADD_ID_CONSTRAINED
string "ssh-rsa"
mpint n
mpint e
mpint d
mpint iqmp
mpint p
mpint q
string comment
constraint[] constraints
"n" is the public composite modulus. "e" is the public exponent. "d" is the private exponent. "p" and "q" are its constituent private prime factors. "iqmp" is the inverse of "q" modulo "p". All of these values, except "iqmp" (which can be calculated from the others), are defined by Section 5.1 of [FIPS.186-5].
「n」は公開合成係数です。「e」は公開指数です。「d」はプライベート指数です。「p」と「q」は、その構成要素であるプライベート素因数です。「iqmp」は「p」を法とした「q」の逆数です。「iqmp」(他の値から計算できる) を除くこれらの値はすべて、[FIPS.186-5] のセクション 5.1 で定義されています。
Agents and their clients MAY support additional key types not documented here. Vendor-specific key types MUST use the domain-qualified naming convention defined in Section 6 of [RFC4251] until codepoints are allocated by IANA [IANA-PUBKEYS].
エージェントとそのクライアントは、ここに記載されていない追加の鍵タイプをサポートしてもよい(MAY)。ベンダー固有の鍵タイプは、コードポイントが IANA [IANA-PUBKEYS] によって割り当てられるまで、[RFC4251] のセクション 6 で定義されているドメイン修飾命名規則を使用しなければなりません (MUST)。
Keys hosted on smart-cards or other hardware tokens may be added using the SSH_AGENTC_ADD_SMARTCARD_KEY and SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED requests. Note that the "constraints" field is only included for the SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED variant of this message.
スマート カードまたはその他のハードウェア トークンでホストされているキーは、SSH_AGENTC_ADD_SMARTCARD_KEY および SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED リクエストを使用して追加できます。「制約」フィールドは、このメッセージの SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED バリアントにのみ含まれることに注意してください。
byte SSH_AGENTC_ADD_SMARTCARD_KEY or
SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
string token id
string PIN
constraint[] constraints
Here "token id" is an opaque identifier for the hardware token and "PIN" is an optional password or PIN to unlock the key. The interpretation of "token id" is not defined by the protocol: it is left solely up to the agent.
ここで、「トークン ID」はハードウェア トークンの不透明な識別子で、「PIN」はキーのロックを解除するためのオプションのパスワードまたは PIN です。「トークン ID」の解釈はプロトコルによって定義されておらず、エージェントにのみ委ねられています。
Typically, only the public components of any keys supported on a hardware token will be loaded into an agent; thus, strictly speaking, this message really arranges for future private key operations to be delegated to the hardware token in question.
通常、ハードウェア トークンでサポートされているキーのパブリック コンポーネントのみがエージェントにロードされます。したがって、厳密に言えば、このメッセージは実際には、将来の秘密キーの操作が問題のハードウェア トークンに委任されるように手配します。
An agent MUST reply with SSH_AGENT_SUCCESS if one or more keys were successfully loaded as a result of one of these messages or with SSH_AGENT_FAILURE if no keys were found. The agent MUST also return SSH_AGENT_FAILURE if the "token id" was not recognised, if the request was against agent policy, or if the agent doesn't support token-hosted keys at all.
エージェントは、これらのメッセージのいずれかの結果として 1 つ以上の鍵が正常にロードされた場合は SSH_AGENT_SUCCESS で応答し、鍵が見つからなかった場合は SSH_AGENT_FAILURE で応答しなければなりません (MUST)。また、「トークン ID」が認識されなかった場合、リクエストがエージェントのポリシーに反していた場合、またはエージェントがトークンでホストされるキーをまったくサポートしていない場合、エージェントは SSH_AGENT_FAILURE を返さなければなりません (MUST)。
A number of constraints may be used in the constrained variants of the key add messages. Each constraint is represented by a type byte followed by zero or more value bytes.
キー追加メッセージの制約付きバリアントでは、多数の制約を使用できます。各制約は、タイプ バイトとそれに続く 0 個以上の値バイトによって表されます。
Zero or more constraints may be specified when adding a key with one of the *_CONSTRAINED requests. Multiple constraints are appended consecutively to the end of the request:
*_CONSTRAINED リクエストの 1 つでキーを追加するときに、0 個以上の制約を指定できます。複数の制約がリクエストの末尾に連続して追加されます。
byte constraint1_type
byte[] constraint1_data
byte constraint2_type
byte[] constraint2_data
....
byte constraintN_type
byte[] constraintN_data
To fully parse a constraint, it is necessary to know its structure beforehand; it is not possible to safely recover when an unrecognised constraint is encountered. Given this, if an agent does not recognise or support a requested constraint, it MUST abort parsing, refuse the request, and return an SSH_AGENT_FAILURE message to the client.
制約を完全に解析するには、その構造を事前に知っておく必要があります。認識できない制約が発生した場合、安全に回復することはできません。これを考慮すると、エージェントが要求された制約を認識またはサポートしない場合、解析を中止し、要求を拒否し、クライアントに SSH_AGENT_FAILURE メッセージを返さなければなりません (MUST)。
The following subsections describe the constraints that have been defined.
次のサブセクションでは、定義されている制約について説明します。
This constraint requests that the agent limit the key's lifetime by deleting it after the specified duration (in seconds) has elapsed from the time the key was added to the agent.
この制約は、キーがエージェントに追加されてから指定された期間 (秒単位) が経過した後にキーを削除することで、キーの有効期間を制限することをエージェントに要求します。
byte SSH_AGENT_CONSTRAIN_LIFETIME
uint32 seconds
This constraint requests that the agent require explicit user confirmation for each private key operation using the key. For example, the agent could present a confirmation dialog before completing a signature operation.
この制約は、エージェントがキーを使用する各秘密キー操作に対して明示的なユーザー確認を要求することを要求します。たとえば、エージェントは署名操作を完了する前に確認ダイアログを表示できます。
byte SSH_AGENT_CONSTRAIN_CONFIRM
Agents may implement experimental or private-use constraints through an extension constraint that supports named constraints.
エージェントは、名前付き制約をサポートする拡張制約を通じて、実験的または私的使用の制約を実装できます。
byte SSH_AGENT_CONSTRAIN_EXTENSION
string extension name
byte[] extension-specific details
The "extension name" MUST consist of a UTF-8 string. Vendor extensions MUST be suffixed by the implementation domain following the naming scheme defined in Section 6 of [RFC4251], e.g., "foo@example.com".
「拡張子名」は UTF-8 文字列で構成する必要があります。ベンダー拡張には、[RFC4251] のセクション 6 で定義されている命名スキームに従って、実装ドメインの接尾辞を付けなければなりません (例: "foo@example.com")。
Note, given the above requirement to reject keys with unsupported constraints, a constraint extension is only usable when both the client and agent support it. Otherwise, the agent will be required to reject the key. This is desirable, as the constraint extension may specify limits on the key that, if ignored, may result in the key being available in situations the user did not intend (i.e., the agent will fail safely).
サポートされていない制約を持つキーを拒否するという上記の要件を考慮すると、制約拡張はクライアントとエージェントの両方がサポートしている場合にのみ使用できることに注意してください。それ以外の場合、エージェントはキーを拒否する必要があります。制約拡張ではキーに対する制限が指定される可能性があるため、これは望ましいことです。制限を無視すると、ユーザーが意図しない状況でキーが使用可能になる可能性があります (つまり、エージェントは安全に失敗します)。
Keys previously loaded into an agent are referred to by their public key blob, which is the standard SSH wire encoding for public keys. SSH protocol key encodings are defined in [RFC4253] for "ssh-rsa" and "ssh-dss" keys, in [RFC5656] for "ecdsa-sha2-*" keys, and in [RFC8709] for "ssh-ed25519" and "ssh-ed448" keys.
以前にエージェントにロードされたキーは、公開キーの標準 SSH ワイヤ エンコーディングである公開キー BLOB によって参照されます。SSH プロトコルのキーエンコーディングは、「ssh-rsa」および「ssh-dss」キーについては [RFC4253] で定義され、「ecdsa-sha2-*」キーについては [RFC5656] で、「ssh-ed25519」および「ssh-ed448」キーについては [RFC8709] で定義されています。
A client may request that an agent remove all keys that it stores:
クライアントは、エージェントに対して、保管しているすべてのキーを削除するよう要求できます。
byte SSH_AGENTC_REMOVE_ALL_IDENTITIES
On receipt of such a message, an agent SHOULD delete all keys that it is holding and reply with SSH_AGENT_SUCCESS; otherwise, it MUST reply with SSH_AGENT_FAILURE if the request was refused.
このようなメッセージを受信したエージェントは、保持しているすべてのキーを削除し、SSH_AGENT_SUCCESS で応答する必要があります (SHOULD)。それ以外の場合、リクエストが拒否された場合は SSH_AGENT_FAILURE で応答しなければなりません。
This request SHOULD be honoured regardless of any agent policy that limits actions that a given client may take; otherwise, a user would be unable to quickly and completely remove their keys in an urgent situation.
このリクエストは、特定のクライアントが実行できるアクションを制限するエージェント ポリシーに関係なく尊重されるべきです。そうしないと、ユーザーは緊急の状況でキーを迅速かつ完全に削除できなくなります。
Specific keys may also be removed:
特定のキーを削除することもできます。
byte SSH_AGENTC_REMOVE_IDENTITY
string key blob
Where "key blob" is the standard public key encoding of the key to be removed (Section 5.3).
ここで、「key blob」は、削除するキーの標準公開キーエンコーディングです (セクション 5.3)。
An agent MUST reply with SSH_AGENT_SUCCESS if the key was deleted or SSH_AGENT_FAILURE if it was not found.
エージェントは、キーが削除された場合は SSH_AGENT_SUCCESS、キーが見つからなかった場合は SSH_AGENT_FAILURE で応答しなければなりません。
Token-hosted keys may be removed from an agent using:
トークンホスト型キーは、以下を使用してエージェントから削除できます。
byte SSH_AGENTC_REMOVE_SMARTCARD_KEY
string token id
string PIN
Where "token id" is an opaque identifier for the hardware token and "PIN" is an optional password or PIN (not typically used), both encoded using UTF-8. Requesting deletion of token-hosted keys SHOULD cause the agent to remove all keys it loaded from the device matching "token id". Similarly to SSH_AGENTC_REMOVE_ALL_IDENTITIES, agents SHOULD honour this request regardless of local policy to allow fast and complete removal of keys. Removing a token-hosted key affects the agent only; it SHOULD NOT cause the keys be deleted from the token itself.
ここで、「トークン ID」はハードウェア トークンの不透明な識別子、「PIN」はオプションのパスワードまたは PIN (通常は使用されません) で、どちらも UTF-8 を使用してエンコードされます。トークンホスト型鍵の削除をリクエストすると、エージェントは「トークン ID」に一致するデバイスからロードしたすべての鍵を削除する必要があります (SHOULD)。SSH_AGENTC_REMOVE_ALL_IDENTITIES と同様に、エージェントはローカル ポリシーに関係なく、キーの迅速かつ完全な削除を許可するためにこのリクエストを尊重する必要があります (SHOULD)。トークンホスト型キーの削除は、エージェントにのみ影響します。トークン自体からキーが削除されるべきではありません。
An agent MUST reply with SSH_AGENT_SUCCESS if the keys were deleted or SSH_AGENT_FAILURE if none were found.
エージェントは、キーが削除された場合は SSH_AGENT_SUCCESS で応答し、キーが見つからなかった場合は SSH_AGENT_FAILURE で応答しなければなりません (MUST)。
A client may request a list of keys from an agent using the following message:
クライアントは、次のメッセージを使用してエージェントにキーのリストを要求できます。
byte SSH_AGENTC_REQUEST_IDENTITIES
The agent MUST reply with a message with the following preamble:
エージェントは、次のプリアンブルを含むメッセージで応答しなければなりません。
byte SSH_AGENT_IDENTITIES_ANSWER
uint32 nkeys
Where "nkeys" indicates the number of keys to follow. Following the preamble are zero or more keys, representing the keys the agent makes available to the client with each encoded as:
ここで、「nkeys」は、たどるキーの数を示します。プリアンブルの後には 0 個以上のキーが続き、エージェントがクライアントに利用可能にするキーを表しており、各キーは次のようにエンコードされています。
string key blob
string comment
Where "key blob" is the standard public key encoding of the key (Section 5.3) and "comment" is a human-readable comment encoded as a UTF-8 string.
ここで、「key blob」はキーの標準公開キーエンコーディング (セクション 5.3) で、「comment」は UTF-8 文字列としてエンコードされた人間が判読できるコメントです。
A client may request that the agent perform a private key signature operation using the following message:
クライアントは、次のメッセージを使用して、エージェントに秘密キー署名操作を実行するように要求できます。
byte SSH_AGENTC_SIGN_REQUEST
string key blob
string data
uint32 flags
Where "key blob" is the key requested to perform the signature (encoded as per Section 5.3), "data" is the data to be signed, and "flags" is a bitfield containing the bitwise OR of zero or more signature flags (see below).
ここで、「key blob」は署名を実行するために要求されたキー (セクション 5.3 に従ってエンコードされた)、「data」は署名されるデータ、「flags」は 0 個以上の署名フラグのビット単位の OR を含むビットフィールドです (以下を参照)。
If the agent does not support the requested flags, or is otherwise unable or unwilling to generate the signature (for example, because it doesn't have the specified key or the user refused confirmation of a constrained key), it MUST reply with an SSH_AGENT_FAILURE message.
エージェントが要求されたフラグをサポートしていない場合、または署名を生成できないか生成したくない場合 (たとえば、指定されたキーを持っていない、またはユーザーが制約されたキーの確認を拒否したため)、エージェントは SSH_AGENT_FAILURE メッセージで応答しなければなりません (MUST)。
On success, the agent MUST reply with:
成功した場合、エージェントは次のように応答する必要があります。
byte SSH_AGENT_SIGN_RESPONSE
string signature
The signature format is specific to the algorithm of the key type in use. SSH protocol signature formats are defined in [RFC4253] for "ssh-rsa" and "ssh-dss" keys, in [RFC5656] for "ecdsa-sha2-*" keys, and in [RFC8709] for "ssh-ed25519" and "ssh-ed448" keys.
署名形式は、使用されている鍵タイプのアルゴリズムに固有です。SSH プロトコルの署名形式は、「ssh-rsa」および「ssh-dss」キーについては [RFC4253] で定義され、「ecdsa-sha2-*」キーについては [RFC5656] で、「ssh-ed25519」および「ssh-ed448」キーについては [RFC8709] で定義されています。
Two flags are currently defined for signature request messages: SSH_AGENT_RSA_SHA2_256 and SSH_AGENT_RSA_SHA2_512 (defined in Section 8.3). These two flags are only valid for "ssh-rsa" keys and request that the agent return a signature using the "rsa-sha2-256" or "rsa-sha2-512" signature methods, respectively. These signature schemes are defined in [RFC8332].
現在、署名要求メッセージには SSH_AGENT_RSA_SHA2_256 と SSH_AGENT_RSA_SHA2_512 (セクション 8.3 で定義) の 2 つのフラグが定義されています。これら 2 つのフラグは「ssh-rsa」キーに対してのみ有効で、エージェントがそれぞれ「rsa-sha2-256」または「rsa-sha2-512」署名メソッドを使用して署名を返すように要求します。これらの署名スキームは [RFC8332] で定義されています。
The agent protocol supports instructing an agent to temporarily lock itself with a passphrase. When locked, an agent MUST suspend processing of sensitive operations (private key signature operations at the very least) until it has been unlocked with the same passphrase.
エージェント プロトコルは、パスフレーズを使用してエージェント自体を一時的にロックするようにエージェントに指示することをサポートしています。ロックされている場合、エージェントは同じパスフレーズでロックが解除されるまで機密操作 (少なくとも秘密鍵署名操作) の処理を一時停止しなければなりません (MUST)。
The following message instructs an agent to lock itself:
次のメッセージは、エージェント自身をロックするように指示します。
byte SSH_AGENTC_LOCK
string passphrase
The agent MUST reply with SSH_AGENT_SUCCESS if locked successfully or SSH_AGENT_FAILURE otherwise (e.g., if the agent was already locked).
エージェントは、正常にロックされた場合は SSH_AGENT_SUCCESS で応答し、それ以外の場合 (たとえば、エージェントがすでにロックされている場合) は SSH_AGENT_FAILURE で応答しなければなりません (MUST)。
The following message requests unlocking an agent:
次のメッセージは、エージェントのロック解除を要求します。
byte SSH_AGENTC_UNLOCK
string passphrase
If the agent is already locked and the passphrase matches the one used to lock it, then it MUST unlock and reply with SSH_AGENT_SUCCESS. If the agent is already unlocked or if the passphrase does not match, it MUST reply with SSH_AGENT_FAILURE.
エージェントがすでにロックされており、パスフレーズがロックに使用されたものと一致する場合は、ロックを解除して SSH_AGENT_SUCCESS で応答する必要があります。エージェントがすでにロック解除されている場合、またはパスフレーズが一致しない場合、エージェントは SSH_AGENT_FAILURE で応答しなければなりません。
The agent protocol includes an optional extension mechanism that allows vendor-specific and experimental messages to be sent via the agent protocol. Extension requests from the client consist of:
エージェント プロトコルには、ベンダー固有の実験的なメッセージをエージェント プロトコル経由で送信できるようにするオプションの拡張メカニズムが含まれています。クライアントからの拡張リクエストは次のもので構成されます。
byte SSH_AGENTC_EXTENSION
string extension type
byte[] extension request-specific contents
The "extension type" indicates the type of the extension message as a UTF-8 string. Implementation-specific extensions MUST be suffixed by the implementation domain following the extension naming scheme defined in Section 6 of [RFC4251], e.g., "foo@example.com".
「拡張子タイプ」は、拡張子メッセージのタイプをUTF-8文字列で示します。実装固有の拡張子には、[RFC4251] のセクション 6 で定義されている拡張子の命名スキームに従って、実装ドメインの接尾辞を付けなければなりません (例: "foo@example.com")。
An agent that does not support extensions of the supplied type MUST reply with an empty SSH_AGENT_FAILURE message. This reply is also sent by agents that do not support the extension mechanism at all.
指定されたタイプの拡張機能をサポートしないエージェントは、空の SSH_AGENT_FAILURE メッセージで応答する必要があります。この応答は、拡張メカニズムをまったくサポートしていないエージェントによっても送信されます。
The contents of successful extension reply messages are specific to the "extension type". Successful extension requests MUST return either SSH_AGENT_SUCCESS on success or an extension-specific response message:
成功した内線応答メッセージの内容は、「内線の種類」に応じて異なります。成功した拡張リクエストは、成功した場合には SSH_AGENT_SUCCESS を返すか、拡張固有の応答メッセージを返さなければなりません。
byte SSH_AGENT_EXTENSION_RESPONSE
string extension type
byte[] extension response-specific contents
Where the "extension type" is the same as that in the request.
ここで、「拡張タイプ」はリクエストのものと同じです。
Extension failure SHOULD be signaled using an SSH_AGENT_EXTENSION_FAILURE message:
拡張機能の失敗は、SSH_AGENT_EXTENSION_FAILURE メッセージを使用して通知されるべきです。
byte SSH_AGENT_EXTENSION_FAILURE
Extensions SHOULD NOT use the standard SSH_AGENT_FAILURE message. This allows failed requests to be distinguished from the extension not being supported.
拡張機能は標準の SSH_AGENT_FAILURE メッセージを使用すべきではありません (SHOULD NOT)。これにより、失敗したリクエストとサポートされていない拡張機能を区別できるようになります。
A single optional extension request "query" is defined to allow a client to query which, if any, extensions are supported by an agent.
単一のオプションの拡張機能リクエスト「クエリ」は、クライアントがエージェントによってサポートされている拡張機能（存在する場合）を照会できるように定義されます。
byte SSH_AGENTC_EXTENSION
string "query"
If an agent supports the query extension, it SHOULD reply with a list of supported extension names.
エージェントがクエリ拡張をサポートしている場合、サポートされている拡張名のリストを応答する必要があります (SHOULD)。
byte SSH_AGENT_EXTENSION_RESPONSE
string "query"
string[] supported extension types
Agents are exposed to the local system using a connection-oriented endpoint. On Unix-like systems, it is typical to arrange for the agent to listen on a filesystem-based Unix domain socket. On Microsoft Windows, it is usual to use a Windows Named Pipe. Access to these endpoints SHOULD be controlled as discussed in Section 10. Multiple clients may access a single agent by making connections to these sockets.
エージェントは、接続指向のエンドポイントを使用してローカル システムに公開されます。Unix のようなシステムでは、ファイル システム ベースの Unix ドメイン ソケットでエージェントがリッスンするように調整するのが一般的です。Microsoft Windows では、通常、Windows 名前付きパイプを使用します。これらのエンドポイントへのアクセスは、セクション 10 で説明したように制御されるべきです (SHOULD)。複数のクライアントは、これらのソケットに接続することによって単一のエージェントにアクセスできます。
In both cases, it is common to expose the name or address of the listening endpoint via an environment variable named "SSH_AUTH_SOCK". Clients of an agent will use this variable to locate and connect to the listening agent. Alternatively, agents MAY use an implicit mechanism for clients to locate their endpoint, such as a default per-user location.
どちらの場合も、「SSH_AUTH_SOCK」という名前の環境変数を介して、リッスンしているエンドポイントの名前またはアドレスを公開するのが一般的です。エージェントのクライアントは、この変数を使用して、リッスンしているエージェントを見つけて接続します。あるいは、エージェントは、ユーザーごとのデフォルトの場所など、クライアントがエンドポイントを見つけるための暗黙的なメカニズムを使用してもよい(MAY)。
Using the connection protocol described in [RFC4254], the agent protocol may be forwarded over an SSH connection. This allows agent forwarding to be requested for any session channel using a model that is similar to the connection protocol's support for X11 Forwarding (Section 6.3 of [RFC4254]). This feature is OPTIONAL for the SSH protocol and agent implementations.
[RFC4254] で説明されている接続プロトコルを使用すると、エージェント プロトコルを SSH 接続経由で転送できます。これにより、X11 転送に対する接続プロトコルのサポート ([RFC4254] のセクション 6.3) と同様のモデルを使用して、任意のセッション チャネルに対してエージェント転送を要求できるようになります。この機能は、SSH プロトコルとエージェントの実装ではオプションです。
Support for agent forwarding may be advertised by an SSH server using the extension mechanism described in [RFC8308] using the name "agent-forward" in the SSH_MSG_EXT_INFO message.
エージェント転送のサポートは、[RFC8308] で説明されている拡張メカニズムを使用し、SSH_MSG_EXT_INFO メッセージ内で「agent-forward」という名前を使用して SSH サーバーによってアドバタイズされる場合があります。
string "agent-forward"
string "0" (version)
Note that this protocol substantially predates the existence of the extension mechanism described in [RFC8308]. Further note that several widely deployed SSH implementations that support agent forwarding do not advertise their ability to do so. SSH clients MAY opportunistically attempt to request agent forwarding in the absence of an advertisement (see [RFC8308]) using the vendor-specific names mentioned below. Likewise, SSH servers MAY implement the vendor-specific names in addition to the one described here.
このプロトコルは、[RFC8308] で説明されている拡張メカニズムが存在するよりも実質的に古いものであることに注意してください。さらに、エージェント転送をサポートする広く導入されているいくつかの SSH 実装では、その機能を宣伝していないことに注意してください。SSH クライアントは、アドバタイズメントがない場合 ([RFC8308] を参照) に、以下に述べるベンダー固有の名前を使用して、便宜的にエージェント転送の要求を試みてもよい(MAY)。同様に、SSH サーバーは、ここで説明されている名前に加えて、ベンダー固有の名前を実装してもよい(MAY)。
An SSH client may request agent forwarding for a previously opened session (see Section 6.1 of [RFC4254]) using the following channel request. This request is sent after the channel has been opened, but before a shell, command, or subsystem has been executed.
SSH クライアントは、次のチャネル要求を使用して、以前に開かれたセッション ([RFC4254] のセクション 6.1 を参照) のエージェント転送を要求できます。このリクエストは、チャネルがオープンされた後、シェル、コマンド、またはサブシステムが実行される前に送信されます。
byte SSH_MSG_CHANNEL_REQUEST
uint32 channel_id
string "agent-req" or "auth-agent-req@openssh.com"
boolean want_reply
Where "channel_id" is the identifier for an established session channel (as returned from a previous SSH_MSG_CHANNEL_OPEN request) and the "want_reply" flag indicates whether the SSH server should respond with a confirmation of whether the request was successful (as specified in Section 5.4 of [RFC4254]).
ここで、"channel_id" は確立されたセッション チャネルの識別子 (前の SSH_MSG_CHANNEL_OPEN リクエストから返されたもの) で、"want_reply" フラグは、SSH サーバーがリクエストが成功したかどうかの確認で応答するかどうかを示します ([RFC4254] のセクション 5.4 で規定されているとおり)。
If an SSH server accepts this request, typically it will arrange to make an endpoint (e.g., a listening socket) available and advertise this fact to the subordinate session. Most implementations on Unix-like systems do this by providing a user-private listening Unix domain socket and recording its location in an environment variable "SSH_AUTH_SOCK".
SSH サーバーがこのリクエストを受け入れる場合、通常、エンドポイント (リスニング ソケットなど) を利用できるように手配し、この事実を下位セッションにアドバタイズします。Unix 系システム上のほとんどの実装では、ユーザー専用のリッスン Unix ドメイン ソケットを提供し、その場所を環境変数「SSH_AUTH_SOCK」に記録することでこれを実現します。
As mentioned previously, many deployed implementations only support the pre-standardisation "auth-agent-req@openssh.com" request name. The "agent-req" name SHOULD only be used if support was explicitly advertised as per Section 7.1.
前述したように、デプロイされた実装の多くは、標準化前の「auth-agent-req@openssh.com」リクエスト名のみをサポートしています。「agent-req」名は、セクション 7.1 に従ってサポートが明示的に宣伝されている場合にのみ使用すべきです (SHOULD)。
After an SSH client has requested that a session have agent forwarding enabled, the SSH server may request a connection to the forwarded agent. The SSH server does this by requesting a dedicated channel to communicate with the SSH client's agent.
SSH クライアントがセッションでエージェント転送を有効にすることを要求した後、SSH サーバーは転送されたエージェントへの接続を要求することがあります。SSH サーバーは、SSH クライアントのエージェントと通信するための専用チャネルを要求することでこれを行います。
byte SSH_MSG_CHANNEL_OPEN
string "agent-connect" or "auth-agent@openssh.com"
uint32 channel_id
uint32 local_window
uint32 local_maxpacket
The "channel_id", "local_window", and "local_maxpacket" fields should be interpreted as specified by Section 5.1 of [RFC4254].
「channel_id」、「local_window」、および「local_maxpacket」フィールドは、[RFC4254] のセクション 5.1 で指定されているように解釈される必要があります。
As above, the "agent-connect" open type name SHOULD only be used if support was explicitly advertised as per Section 7.1.
上記のように、「agent-connect」オープンタイプ名は、セクション 7.1 に従ってサポートが明示的に宣伝されている場合にのみ使用されるべきです(SHOULD)。
An SSH client SHOULD be prepared to handle multiple concurrent forwarded connections to a client-side agent; otherwise, requests to access the agent from the remote side that happen to overlap prior requests may fail. Overlapping requests may occur because the SSH connection protocol [RFC4254] allows multiple user sessions over a single transport (see [RFC4253]), which may each request use of the agent independently and potentially concurrently.
SSH クライアントは、クライアント側エージェントへの複数の同時転送接続を処理できるように準備する必要があります (SHOULD)。そうしないと、前のリクエストと偶然重複してリモート側からエージェントにアクセスするリクエストが失敗する可能性があります。SSH 接続プロトコル [RFC4254] では、単一のトランスポート上で複数のユーザー セッションが許可されており ([RFC4253] を参照)、それぞれが独立して、場合によっては同時にエージェントの使用を要求する可能性があるため、リクエストの重複が発生する可能性があります。
An SSH client MAY accept agent connection requests (subject to authorisation) without a prior agent forwarding request having been made to support the situation where agent forwarding without opening a session is desired. Similarly, an SSH client MAY continue to accept agent connection requests after the session for which agent forwarding was requested has closed.
SSH クライアントは、セッションを開かずにエージェント転送が必要な状況をサポートするために、事前のエージェント転送リクエストがなくても、エージェント接続リクエストを (認可の対象として) 受け入れることができます (MAY)。同様に、SSH クライアントは、エージェント転送が要求されたセッションが終了した後も、エージェント接続要求を受け入れ続けることができます (MAY)。
An SSH client MUST refuse unauthorised agent connection requests, when agent forwarding is neither requested nor desired by the SSH client but an SSH server sends an agent connection request anyway.
SSH クライアントは、エージェント転送が SSH クライアントによって要求されても望まれてもいないにもかかわらず、とにかく SSH サーバーがエージェント接続要求を送信する場合、未承認のエージェント接続要求を拒否しなければなりません (MUST)。
Because the "agent-connect" request contains no identifier to distinguish which session channel originated the connection request, an SSH connection can effectively forward access to only a single SSH client-side agent using this protocol (although there may be multiple concurrent connections to that single agent).
「agent-connect」リクエストには、どのセッション チャネルが接続リクエストを発信したかを区別する識別子が含まれていないため、SSH 接続は、このプロトコルを使用して 1 つの SSH クライアント側エージェントにのみアクセスを効果的に転送できます (ただし、その 1 つのエージェントに対して複数の同時接続が存在する可能性があります)。
The following numbers are used as message types for requests from the client to the agent.
クライアントからエージェントへのリクエストのメッセージタイプとして次の番号が使用されます。
+------------------------------------------+----+
| SSH_AGENTC_REQUEST_IDENTITIES | 11 |
+------------------------------------------+----+
| SSH_AGENTC_SIGN_REQUEST | 13 |
+------------------------------------------+----+
| SSH_AGENTC_ADD_IDENTITY | 17 |
+------------------------------------------+----+
| SSH_AGENTC_REMOVE_IDENTITY | 18 |
+------------------------------------------+----+
| SSH_AGENTC_REMOVE_ALL_IDENTITIES | 19 |
+------------------------------------------+----+
| SSH_AGENTC_ADD_SMARTCARD_KEY | 20 |
+------------------------------------------+----+
| SSH_AGENTC_REMOVE_SMARTCARD_KEY | 21 |
+------------------------------------------+----+
| SSH_AGENTC_LOCK | 22 |
+------------------------------------------+----+
| SSH_AGENTC_UNLOCK | 23 |
+------------------------------------------+----+
| SSH_AGENTC_ADD_ID_CONSTRAINED | 25 |
+------------------------------------------+----+
| SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED | 26 |
+------------------------------------------+----+
| SSH_AGENTC_EXTENSION | 27 |
+------------------------------------------+----+
Table 1
The following numbers are used as message types for replies from the agent to the client.
エージェントからクライアントへの返信のメッセージタイプとして次の番号が使用されます。
+------------------------------+----+
| SSH_AGENT_FAILURE | 5 |
+------------------------------+----+
| SSH_AGENT_SUCCESS | 6 |
+------------------------------+----+
| SSH_AGENT_IDENTITIES_ANSWER | 12 |
+------------------------------+----+
| SSH_AGENT_SIGN_RESPONSE | 14 |
+------------------------------+----+
| SSH_AGENT_EXTENSION_FAILURE | 28 |
+------------------------------+----+
| SSH_AGENT_EXTENSION_RESPONSE | 29 |
+------------------------------+----+
Table 2
The following message type numbers are reserved for implementations that implement support for the legacy SSH protocol version 1: 1-4, 7-10, 15-16, and 24 (inclusive). These message numbers MAY be used by an implementation supporting the legacy protocol but MUST NOT be reused otherwise.
次のメッセージ タイプ番号は、レガシー SSH プロトコル バージョン 1 のサポートを実装する実装用に予約されています: 1 ～ 4、7 ～ 10、15 ～ 16、および 24 (両端を含む)。これらのメッセージ番号は、レガシープロトコルをサポートする実装によって使用されてもよいが、それ以外の方法で再利用してはなりません。
Message number 0 is also reserved and MUST NOT be used.
メッセージ番号 0 も予約されており、使用してはなりません。
The range of message numbers 240-255 is reserved for Private Use extensions to the agent protocol and MUST NOT be used by generic implementations (see [RFC8126] for more information on Private Use).
メッセージ番号 240 ～ 255 の範囲は、エージェント プロトコルの私的使用拡張用に予約されており、一般的な実装では使用してはなりません (私的使用の詳細については [RFC8126] を参照してください)。
The following numbers are used to identify key constraints. These are only used in key constraints and are not sent as message numbers.
次の番号は、主要な制約を識別するために使用されます。これらはキー制約でのみ使用され、メッセージ番号として送信されません。
+-------------------------------+-----+
| SSH_AGENT_CONSTRAIN_LIFETIME | 1 |
+-------------------------------+-----+
| SSH_AGENT_CONSTRAIN_CONFIRM | 2 |
+-------------------------------+-----+
| SSH_AGENT_CONSTRAIN_EXTENSION | 255 |
+-------------------------------+-----+
Table 3
The constraint identifier 0 is reserved.
制約識別子 0 は予約されています。
The following numbers may be present in signature request (SSH_AGENTC_SIGN_REQUEST) messages. These flags form a bit field by taking the logical OR of zero or more flags.
署名要求 (SSH_AGENTC_SIGN_REQUEST) メッセージには、次の番号が含まれる場合があります。これらのフラグは、0 個以上のフラグの論理 OR を演算してビット フィールドを形成します。
+------------------------+------------+
| SSH_AGENT_RSA_SHA2_256 | 0x00000002 |
+------------------------+------------+
| SSH_AGENT_RSA_SHA2_512 | 0x00000004 |
+------------------------+------------+
Table 4
The flag value 1 is reserved for historical implementations.
フラグ値 1 は、過去の実装のために予約されています。
This protocol describes the establishment of five registries: one for message type numbers, one for constraint numbers, one for signature request flags, one for constraint extension names, and one for extension request names. Additionally, new codepoints are requested in three existing registries.
このプロトコルは、メッセージ タイプ番号用、制約番号用、署名要求フラグ用、制約拡張名用、および拡張要求名用の 5 つのレジストリの確立について説明します。さらに、3 つの既存のレジストリで新しいコードポイントが要求されます。
When a Designated Expert (DE) is asked to review additions to the new registries described in this document (Section 9.2, Section 9.3, Section 9.5, and Section 9.6), they are requested to verify that suitable documentation as described in [RFC8126] exists and is permanently and publicly available. The DE is also requested to check the clarity of purpose and use of the requested codepoints. The DE should also verify that specifications produced in the IETF that request codepoints in these registries have been made available to the SSHM Working Group and the ssh@ietf.org mailing list for review. Requests for codepoints made for specifications produced outside the IETF should not conflict with active IETF work or prior IETF specifications.
指定専門家 (DE) が、この文書 (セクション 9.2、セクション 9.3、セクション 9.5、およびセクション 9.6) に記載されている新しいレジストリへの追加内容のレビューを依頼される場合、[RFC8126] に記載されている適切な文書が存在し、永続的かつ公的に利用可能であることを確認することが求められます。DE は、要求されたコードポイントの目的と使用法の明確性をチェックすることも要求されます。DE はまた、これらのレジストリ内のコードポイントを要求する IETF で作成された仕様が、レビューのために SSHM ワーキング グループおよび ssh@ietf.org メーリング リストに提供されていることも確認する必要があります。IETF の外部で作成された仕様に対して行われたコードポイントの要求は、アクティブな IETF 作業または以前の IETF 仕様と競合してはなりません。
The available number of codepoints in the SSH agent protocol numbers (Section 9.2), constraint numbers (Section 9.3), and SSH agent signature flags (Section 9.5) registries are limited, so the DE is requested to ensure the use of codepoints is very well justified. For the SSH agent protocol message numbers, named extension requests (Section 9.6) provide an alternative for most uses with no practical limitation on the number of available codepoints. For key constraint numbers, the constraint extension mechanism (Section 5.2.7.3) provides a similar alternative that is not limited by available codepoints.
SSH エージェントのプロトコル番号 (セクション 9.2)、制約番号 (セクション 9.3)、および SSH エージェントの署名フラグ (セクション 9.5) レジストリで使用できるコードポイントの数は制限されているため、DE はコードポイントの使用が十分に正当化されていることを確認する必要があります。SSH エージェント プロトコル メッセージ番号については、名前付き拡張リクエスト (セクション 9.6) が、使用可能なコードポイントの数に実質的な制限を設けずに、ほとんどの用途に代替手段を提供します。主要な制約番号については、制約拡張メカニズム (セクション 5.2.7.3) が、利用可能なコードポイントに制限されない同様の代替手段を提供します。
The "SSH Agent Protocol Message Type Numbers" registry records the message type numbers for client requests and agent responses. It is located in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH]. Its initial state consists of the following numbers and reservations. Future message number allocations shall occur via Expert Review as per [RFC8126].
「SSH エージェント プロトコル メッセージ タイプ番号」レジストリには、クライアント要求とエージェント応答のメッセージ タイプ番号が記録されます。これは、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] にあります。初期状態は次の番号と予約で構成されます。将来のメッセージ番号の割り当ては、[RFC8126] に従って専門家レビューを通じて行われます。
+=========+==========================================+=============+
| Number | Identifier | Reference |
+=========+==========================================+=============+
| 0 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 1 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 2 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 3 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 4 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 5 | SSH_AGENT_FAILURE | RFC 9987, |
| | | Sections |
| | | 5.1 and 8.1 |
+---------+------------------------------------------+-------------+
| 6 | SSH_AGENT_SUCCESS | RFC 9987, |
| | | Sections |
| | | 5.1 and 8.1 |
+---------+------------------------------------------+-------------+
| 7 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 8 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 9 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 10 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 11 | SSH_AGENTC_REQUEST_IDENTITIES | RFC 9987, |
| | | Sections |
| | | 5.5 and 8.1 |
+---------+------------------------------------------+-------------+
| 12 | SSH_AGENT_IDENTITIES_ANSWER | RFC 9987, |
| | | Sections |
| | | 5.5 and 8.1 |
+---------+------------------------------------------+-------------+
| 13 | SSH_AGENTC_SIGN_REQUEST | RFC 9987, |
| | | Sections |
| | | 5.6 and 8.1 |
+---------+------------------------------------------+-------------+
| 14 | SSH_AGENT_SIGN_RESPONSE | RFC 9987, |
| | | Sections |
| | | 5.6 and 8.1 |
+---------+------------------------------------------+-------------+
| 15 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 16 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 17 | SSH_AGENTC_ADD_IDENTITY | RFC 9987, |
| | | Sections |
| | | 5.2 and 8.1 |
+---------+------------------------------------------+-------------+
| 18 | SSH_AGENTC_REMOVE_IDENTITY | RFC 9987, |
| | | Sections |
| | | 5.4 and 8.1 |
+---------+------------------------------------------+-------------+
| 19 | SSH_AGENTC_REMOVE_ALL_IDENTITIES | RFC 9987, |
| | | Sections |
| | | 5.4 and 8.1 |
+---------+------------------------------------------+-------------+
| 20 | SSH_AGENTC_ADD_SMARTCARD_KEY | RFC 9987, |
| | | Sections |
| | | 5.2.6 and |
| | | 8.1 |
+---------+------------------------------------------+-------------+
| 21 | SSH_AGENTC_REMOVE_SMARTCARD_KEY | RFC 9987, |
| | | Sections |
| | | 5.4 and 8.1 |
+---------+------------------------------------------+-------------+
| 22 | SSH_AGENTC_LOCK | RFC 9987, |
| | | Sections |
| | | 5.7 and 8.1 |
+---------+------------------------------------------+-------------+
| 23 | SSH_AGENTC_UNLOCK | RFC 9987, |
| | | Sections |
| | | 5.7 and 8.1 |
+---------+------------------------------------------+-------------+
| 24 | Reserved | RFC 9987, |
| | | Section |
| | | 8.1.1 |
+---------+------------------------------------------+-------------+
| 25 | SSH_AGENTC_ADD_ID_CONSTRAINED | RFC 9987, |
| | | Sections |
| | | 5.2 and 8.1 |
+---------+------------------------------------------+-------------+
| 26 | SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED | RFC 9987, |
| | | Sections |
| | | 5.2.6 and |
| | | 8.1 |
+---------+------------------------------------------+-------------+
| 27 | SSH_AGENTC_EXTENSION | RFC 9987, |
| | | Sections |
| | | 5.8 and 8.1 |
+---------+------------------------------------------+-------------+
| 28 | SSH_AGENT_EXTENSION_FAILURE | RFC 9987, |
| | | Sections |
| | | 5.8 and 8.1 |
+---------+------------------------------------------+-------------+
| 29 | SSH_AGENT_EXTENSION_RESPONSE | RFC 9987, |
| | | Sections |
| | | 5.8 and 8.1 |
+---------+------------------------------------------+-------------+
| 240-255 | Private Use | RFC 9987, |
| | | Section 8.1 |
+---------+------------------------------------------+-------------+
Table 5
The "SSH Agent Key Constraint Numbers" registry records the message numbers for key use constraints. It is located in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH]. Its initial state is as follows. Future key constraint number allocations shall occur via Expert Review as per [RFC8126].
「SSH エージェント キー制約番号」レジストリには、キー使用制約のメッセージ番号が記録されます。これは、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] にあります。初期状態は以下の通りです。将来の鍵制約番号の割り当ては、[RFC8126] に従って専門家レビューを通じて行われます。
+========+===============================+=======================+
| Number | Identifier | Reference |
+========+===============================+=======================+
| 0 | Reserved | RFC 9987, Section 8.2 |
+--------+-------------------------------+-----------------------+
| 1 | SSH_AGENT_CONSTRAIN_LIFETIME | RFC 9987, Section 8.2 |
+--------+-------------------------------+-----------------------+
| 2 | SSH_AGENT_CONSTRAIN_CONFIRM | RFC 9987, Section 8.2 |
+--------+-------------------------------+-----------------------+
| 255 | SSH_AGENT_CONSTRAIN_EXTENSION | RFC 9987, Section 8.2 |
+--------+-------------------------------+-----------------------+
Table 6
The "SSH Agent Key Constraint Extension Names" registry records the names used in the SSH_AGENT_CONSTRAIN_EXTENSION constraint extension type (Section 5.2.7.3). It is located in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH]. Its initial state is empty. Future key constraint extension name allocations shall occur via Expert Review as per [RFC8126].
「SSH エージェント キー制約拡張名」レジストリには、SSH_AGENT_CONSTRAIN_EXTENSION 制約拡張タイプ (セクション 5.2.7.3) で使用される名前が記録されます。これは、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] にあります。初期状態は空です。将来のキー制約拡張名の割り当ては、[RFC8126] に従って専門家レビューを通じて行われます。
The "SSH Agent Signature Flags" registry records the values for signature request (SSH_AGENTC_SIGN_REQUEST) flag values. It is located in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH]. Its initial state consists of the following numbers. Note that as the flags are combined by bitwise OR, all flag values must be powers of two and the maximum available flag value is 0x80000000.
「SSH エージェント署名フラグ」レジストリには、署名要求 (SSH_AGENTC_SIGN_REQUEST) フラグの値が記録されます。これは、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] にあります。初期状態は以下の数値で構成されます。フラグはビットごとの OR によって結合されるため、すべてのフラグ値は 2 の累乗である必要があり、使用可能な最大フラグ値は 0x80000000 であることに注意してください。
Future signature flag allocations shall occur via Expert Review as per [RFC8126].
将来の署名フラグの割り当ては、[RFC8126] に従って専門家レビューを通じて行われます。
+========+========================+=======================+
| Number | Identifier | Reference |
+========+========================+=======================+
| 0x01 | Reserved | RFC 9987, Section 8.3 |
+--------+------------------------+-----------------------+
| 0x02 | SSH_AGENT_RSA_SHA2_256 | RFC 9987, Section 8.3 |
+--------+------------------------+-----------------------+
| 0x04 | SSH_AGENT_RSA_SHA2_512 | RFC 9987, Section 8.3 |
+--------+------------------------+-----------------------+
Table 7
The "SSH Agent Extension Request Names" registry records the names used in the generic extension request message (SSH_AGENTC_EXTENSION). It is located in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH]. Its initial state consists of the following names.
「SSH エージェント拡張要求名」レジストリには、汎用拡張要求メッセージ (SSH_AGENTC_EXTENSION) で使用される名前が記録されます。これは、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] にあります。初期状態は以下の名前で構成されています。
Future name allocations shall occur via Expert Review as per [RFC8126].
将来の名前の割り当ては、[RFC8126] に従って専門家レビューを通じて行われます。
+================+=========================+
| Extension Name | Reference |
+================+=========================+
| query | RFC 9987, Section 5.8.1 |
+----------------+-------------------------+
Table 8
IANA has added the following entries to the "Extension Names" registry [IANA-SSH-EXT] in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH].
IANA は、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] の「Extension Names」レジストリ [IANA-SSH-EXT] に次のエントリを追加しました。
+================+=======================+
| Extension Name | Reference |
+================+=======================+
| agent-forward | RFC 9987, Section 7.1 |
+----------------+-----------------------+
Table 9
IANA has added the following entries to the "Connection Protocol Channel Request Names" registry [IANA-SSH-CHANREQ] in the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH].
IANA は、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] の「Connection Protocol Channel Request Names」レジストリ [IANA-SSH-CHANREQ] に次のエントリを追加しました。
+==============+=======================+
| Request Type | Reference |
+==============+=======================+
| agent-req | RFC 9987, Section 7.2 |
+--------------+-----------------------+
Table 10
IANA has added the following entries to the "Connection Protocol Channel Types" registry [IANA-SSH-CHANTYPE] under the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH].
IANA は、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] の下の「Connection Protocol Channel Types」レジストリ [IANA-SSH-CHANTYPE] に次のエントリを追加しました。
+===============+=======================+
| Channel Type | Reference |
+===============+=======================+
| agent-connect | RFC 9987, Section 7.3 |
+---------------+-----------------------+
Table 11
The agent is a service that is tasked with retaining and providing controlled access to what are typically long-lived login authentication credentials. It is, by nature, a sensitive and trusted software component. Moreover, the agent protocol itself does not include any authentication or transport security; ability to communicate with an agent is usually sufficient to invoke it to perform private key operations.
エージェントは、通常は有効期間が長いログイン認証資格情報を保持し、その資格情報への制御されたアクセスを提供することを任務とするサービスです。これは本質的に、機密性が高く信頼できるソフトウェア コンポーネントです。さらに、エージェント プロトコル自体には認証やトランスポート セキュリティが含まれていません。通常、エージェントと通信する機能があれば、エージェントを呼び出して秘密キー操作を実行できます。
Since being able to access an agent is usually sufficient to perform private key operations, it is critically important that the agent only be exposed to its owner and their authorised delegates. On Unix-like systems, this may be achieved via filesystem permissions on the agent socket and/or identity checks on the client connected to a socket (e.g., SO_PEERCRED on some Unix-like systems). On Windows, access to a named pipe may be controlled by attaching a security descriptor at the time of its creation.
通常、秘密キー操作を実行するにはエージェントにアクセスできれば十分であるため、エージェントをその所有者とその権限のある代理人にのみ公開することが非常に重要です。Unix 系システムでは、これは、エージェント ソケット上のファイル システム パーミッションや、ソケットに接続されているクライアント上の ID チェック (たとえば、一部の Unix 系システムの SO_PEERCRED) によって実現される場合があります。Windows では、名前付きパイプの作成時にセキュリティ記述子を付加することで、名前付きパイプへのアクセスを制御できます。
The primary design intention of an agent is that an attacker with unprivileged access to their victim's agent should be prevented from gaining a copy of any keys that have been loaded into it. This may not preclude the attacker from stealing use of those keys (e.g., if they have been loaded without a confirmation constraint).
エージェントの主な設計意図は、被害者のエージェントに非特権アクセスを持つ攻撃者が、そのエージェントにロードされているキーのコピーを入手できないようにすることです。これは、攻撃者がこれらのキーを盗用することを妨げない可能性があります (たとえば、キーが確認制約なしでロードされている場合)。
Given this, the agent should, as far as possible, prevent its memory from being read by other processes to prevent theft of loaded keys. Typically, this includes disabling debugging interfaces and preventing process memory dumps on abnormal termination.
これを考慮すると、エージェントは、ロードされたキーの盗難を防ぐために、他のプロセスによってメモリが読み取られるのを可能な限り防止する必要があります。通常、これには、デバッグ インターフェイスの無効化と、異常終了時のプロセス メモリ ダンプの防止が含まれます。
Another, more subtle, means by which keys may be stolen is via cryptographic side-channels. Private key operations may leak information about the contents of keys via differences in timing, power use, or by side effects in the memory subsystems (e.g., CPU caches) of the host running the agent. For the case of a local attacker and an agent holding unconstrained keys, the only limit on the number of private key operations the attacker may be able to observe is the rate at which the CPU can perform signatures. This grants the attacker an almost ideal oracle for side-channel attacks. While a full treatment of side-channel attacks is beyond the scope of this specification, agents SHOULD use cryptographic implementations that are resistant to side-channel attacks and MAY take additional measures to hide the actual time spent processing private key operations. Failure to do so may expose keys to recovery through these side-channels.
キーが盗まれるもう 1 つの、より巧妙な手段は、暗号化サイドチャネル経由です。秘密キーの操作では、タイミングの違い、電力使用、またはエージェントを実行しているホストのメモリ サブシステム (CPU キャッシュなど) の副作用によって、キーの内容に関する情報が漏洩する可能性があります。ローカル攻撃者と制約のない鍵を保持するエージェントの場合、攻撃者が観察できる秘密鍵操作の数の唯一の制限は、CPU が署名を実行できる速度です。これにより、攻撃者はサイドチャネル攻撃にとってほぼ理想的な手段を得ることができます。サイドチャネル攻撃の完全な処理はこの仕様の範囲を超えていますが、エージェントはサイドチャネル攻撃に耐性のある暗号実装を使用すべきであり、秘密鍵操作の処理に実際に費やされた時間を隠すために追加の措置を講じてもよいです。そうしないと、これらのサイドチャネルを通じて回復の鍵が公開される可能性があります。
Forwarding access to a local agent over an SSH connection (Section 7) inherently creates a transitive trust relationship. SSH implementations SHOULD NOT forward use of an agent by default, and users SHOULD NOT forward use of an agent to hosts that are not fully trusted, as doing so could expose access to the user's keys to attackers on remote hosts. Agents SHOULD implement additional controls over key visibility and use for forwarded agent connections; otherwise, the user has only an all-or-nothing choice about whether to forward an agent.
SSH 接続を介したローカル エージェントへのアクセスの転送 (セクション 7) では、本質的に推移的な信頼関係が作成されます。SSH 実装は、デフォルトでエージェントの使用を転送してはなりません (SHOULD NOT)。また、ユーザーは、完全に信頼されていないホストにエージェントの使用を転送してはなりません (そうすることで、ユーザーのキーへのアクセスがリモート ホスト上の攻撃者に公開される可能性があるため)。エージェントは、キーの可視性と転送されたエージェント接続の使用に対する追加の制御を実装する必要があります。それ以外の場合、ユーザーにはエージェントを転送するかどうかについての選択肢しかありません。
Implementation of keys hosted by a token or smartcard requires some care, too. On some systems, tokens may be invoked by providing a path to a shared library that must be loaded to make use of keys hosted on the device (a path to a library for a particular PKCS#11 module, for example). Loading a shared library on most platforms implies automatic execution of code in that library in the address space of the process that loads it. To avoid the loading of potentially hostile code, agents that support loading token-hosted keys via a library path SHOULD ensure that only trusted token provider libraries are loadable. Additionally, agents SHOULD ensure that loaded token library code cannot gain access to other keys loaded in the agent and MAY disallow remote clients from loading token keys entirely. Protection for existing keys from a token library code may be achieved by loading the token library into a separate process to the agent and arranging for the agent to invoke token operations to this process via IPC.
トークンまたはスマートカードによってホストされるキーの実装にも注意が必要です。一部のシステムでは、デバイス上でホストされているキーを使用するためにロードする必要がある共有ライブラリへのパス (たとえば、特定の PKCS#11 モジュールのライブラリへのパス) を提供することによってトークンが呼び出される場合があります。ほとんどのプラットフォームで共有ライブラリをロードすると、それをロードするプロセスのアドレス空間でそのライブラリ内のコードが自動的に実行されます。潜在的に敵対的なコードのロードを回避するために、ライブラリ パスを介したトークンホスト型キーのロードをサポートするエージェントは、信頼されたトークン プロバイダー ライブラリのみがロード可能であることを保証する必要があります (SHOULD)。さらに、エージェントは、ロードされたトークン ライブラリ コードがエージェントにロードされた他のキーにアクセスできないことを保証する必要があり (SHOULD)、リモート クライアントがトークン キーをロードすることを完全に禁止してもよい (MAY)。トークン ライブラリ コードからの既存のキーの保護は、トークン ライブラリをエージェントの別のプロセスにロードし、エージェントが IPC を介してこのプロセスに対してトークン操作を呼び出すように手配することによって実現できます。
Finally, with respect to the agent locking functionality in Section 5.7, an agent SHOULD take countermeasures against brute-force guessing attacks on the passphrase. This may take the form of enforced delays when an unlock attempt is made with an incorrect password (potentially increasing for subsequent failures), a lockout period where the agent refuses to accept further requests after some threshold of failed unlock attempts has been made, and/or deletion of all keys held by the agent after a threshold of failed unlock attempts.
最後に、セクション 5.7 のエージェントのロック機能に関して、エージェントはパスフレーズに対するブルートフォース推測攻撃に対する対策を講じるべきです(SHOULD)。これは、ロック解除試行が間違ったパスワードで行われた場合の遅延の強制 (その後の失敗で増加する可能性がある)、ロック解除試行の失敗が一定のしきい値に達した後にエージェントがそれ以上の要求の受け入れを拒否するロックアウト期間、および/またはロック解除試行の失敗がしきい値に達した後にエージェントが保持するすべてのキーの削除の形をとる場合があります。
[FIPS.186-4]
NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-4,
DOI 10.6028/NIST.FIPS.186-4, June 2013,
<https://doi.org/10.6028/NIST.FIPS.186-4>.
[FIPS.186-5]
NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://doi.org/10.6028/NIST.FIPS.186-5>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
the Secure Shell (SSH) Protocol", RFC 8332,
DOI 10.17487/RFC8332, March 2018,
<https://www.rfc-editor.org/info/rfc8332>.
[RFC8709] Harris, B. and L. Velvindron, "Ed25519 and Ed448 Public
Key Algorithms for the Secure Shell (SSH) Protocol",
RFC 8709, DOI 10.17487/RFC8709, February 2020,
<https://www.rfc-editor.org/info/rfc8709>.
[IANA-PUBKEYS]
IANA, "Public Key Algorithm Names",
<https://www.iana.org/assignments/ssh-parameters/>.
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters/>.
[IANA-SSH-CHANREQ]
IANA, "Connection Protocol Channel Types",
<https://www.iana.org/assignments/ssh-parameters/>.
[IANA-SSH-CHANTYPE]
IANA, "Extension Names",
<https://www.iana.org/assignments/ssh-parameters/>.
[IANA-SSH-EXT]
IANA, "Connection Protocol Channel Request Names",
<https://www.iana.org/assignments/ssh-parameters/>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
This protocol was designed and first implemented by Markus Friedl, based on a similar protocol for an agent to support the legacy SSH version 1 by Tatu Ylonen.
このプロトコルは、Tatu Ylonen による従来の SSH バージョン 1 をサポートするエージェント用の同様のプロトコルに基づいて、Markus Friedl によって設計され、最初に実装されました。
Thanks to Simon Tatham, Niels Möller, James Spencer, Simon Josefsson, Matt Johnston, Jakub Jelen, Rich Salz, Caspar Schutijser, Florian Obser, Martin Thomson, Deb Cooley, and Tero Kivinen who reviewed and helped improve this document.
このドキュメントのレビューと改善に協力してくれた Simon Tatham、Niels Möller、James Spencer、Simon Josefsson、Matt Johnston、Jakub Jelen、Rich Salz、Caspar Schutijser、Florian Obser、Martin Thomson、Deb Cooley、Tero Kivinen に感謝します。
Damien Miller
OpenSSH
Email: djm@openssh.com
URI: https://www.openssh.com/