---
title: "ERPC CLI にログインし、鍵の置き場所を確かめる"
description: "このマシンで ERPC アカウントにログインし、ERPC CLI がセッションを置く場所を選びます。ノードの鍵と erpc が書くファイルの置き場所も確かめられます。"
canonical: "https://erpc.global/ja/doc/erpc-cli/sign-in-and-keys/"
locale: "ja"
---

# ERPC CLI にログインし、鍵の置き場所を確かめる

このマシンでログインすると、ERPC CLI はセッションをキーチェーンか 1Password に置きます。このページでは、ノードの鍵の置き場所と、erpc が置くファイルも説明します。

このページは、プレリリースの ERPC CLI `v0.1.0-rc.4` について説明しています。

## ログインする

```bash
erpc signup     # opens the sign-up page
erpc login      # signs this machine in; the session goes to the keychain or 1Password
erpc whoami
```

`erpc login` は、OAuth のデバイス認可グラント（device authorization grant）でセッションを受け取ります。ブラウザのないマシンでは、`erpc login --no-browser` がブラウザを開く代わりに URL とコードを表示し、`erpc signup --no-browser` はアカウント登録の URL を表示します。`erpc whoami` は保存したセッションが誰のものかを表示し、`erpc logout` はログアウトして保存したセッションを消します。

## セッションの置き場所を選ぶ

ターミナルでは、`erpc login` がどのストアを使うかを聞きます。既定は OS のキーチェーンで、1Password が応答すれば 1Password も選べます。`--store` と `--vault` を付けると聞かずに決まり、その選択は `config.toml` に記録され、ほかのコマンドもそこを読みます。

| `--store` | セッションの置き場所 |
| --- | --- |
| `keychain` | OS のキーチェーン |
| `1password-desktop`（`1password`、`op` も可） | 1Password（デスクトップアプリ経由） |
| `1password-service-account` | 1Password（サービスアカウントのトークン経由） |
| `file` | ディスク上のファイル。このマシンにシークレットが残ります |

指定も記録もないときは、`OP_SERVICE_ACCOUNT_TOKEN` が設定されていれば 1Password のサービスアカウントを、なければ OS のキーチェーンがあればそれを、それもなければ erpc の状態ディレクトリのファイルを使います。どのストアを使っていて、なぜそうなったかは `erpc doctor` が報告します。サービスアカウントを使うとき、erpc は `OP_SERVICE_ACCOUNT_TOKEN` を自分が起動する `op` のプロセスにだけ渡し、このトークンをどこにも書きません。

1Password のアイテムにはマシンの名前が付くので、2 台のマシンが 1 つのセッションを共有することはありません。名前は `ERPC_HOST_LABEL` で上書きできます。

### Linux の場合

Secret Service が応答する環境では、キーチェーンは Secret Service です。それ以外では、カーネルがユーザーごとに持つ永続キーリングを使います。これはメモリー上にあり、ディスクには書かれません。セッションは再起動するか数日使わないまで続き、その後はもう一度 `erpc login` を求められます。自分のログインを持たずに始めたシェル（`-` なしの `su`、`sudo -E`）ではこのキーリングを使えないため、erpc は理由を示して処理を断ります。

### macOS の場合

erpc は `/usr/bin/security` を通してキーチェーンを使います。あなたとして動くほかのプログラムも、同じく `security` を実行すればセッションを読めます。一方でキーチェーンは、保存中のセッションを暗号化したまま保ち、ほかのユーザーからは読めないようにします。

### セッションがディスクに置かれるとき

erpc がセッションを状態ディレクトリに書くのは 3 つの場合です。`file` ストアを使うとき、退避したセッション（ローテーションしたリフレッシュトークンがストアに届かなかったもの）のとき、書き込みが途中で止まった後です。こうしたファイルがある間は、`erpc doctor` がそれぞれを報告します。Unix ではこれらのファイルはモード `0600` で作られます。Windows では、erpc は独自の権限を設定しません。

## ノードの鍵の置き場所

ノードの台帳と、各チェーンのガイドが挙げる元の鍵のバックアップは、1Password に置かれます。すべての鍵が 1Password にあるわけではなく、ノードが動くために必要な鍵をホストに持つこともあります。ホストにあるものは自分でバックアップしてください。バックアップなしにそのホストを作り直すと、失われます。また、稼働中の Sui のバリデータと、選出された TRON の witness は、新しいホストへの移動を受け付けません。

| ノード | 1Password にあるもの | ホストにあるもの |
| --- | --- | --- |
| Solana バリデータ（native） | 自分で作ったアイデンティティと同期用のキーペア。投票アカウントと引き出し権限は、公開鍵としてだけ erpc に渡します | 同期用のキーペア（そのホスト向けに暗号化）と、`--activate-validator` 以降はアイデンティティも。投票アカウントと引き出しの鍵は取り込まれません |
| Solana バリデータ（solv） | ステークされたアイデンティティと、公開鍵だけを渡した場合を除いて引き出し権限。投票アカウントの鍵は、アカウントの確認が済むと削除されます | 使い捨ての `unstaked-identity.json`（平文）。デプロイがステークされた鍵や引き出し権限をノードにコピーすることはありません |
| Solana RPC（native） | 自分で作ったアイデンティティ | 同じアイデンティティ（そのホスト向けに暗号化） |
| Solana RPC（solv） | 台帳 | そのホストで作ったアイデンティティ。ホストの外へは出ません |
| Ethereum バリデータ | 台帳 | キーストア、その解錠パスワード、スラッシングの履歴。バックアップの履歴はスナップショットの時点で止まるため、その後に署名した鍵を復元するとスラッシュされることがあります。署名者の移動は `erpc v --chain eth migrate` で行います |
| Arc RPC | コンセンサスの鍵 | 暗号化したコンセンサスの鍵 |
| Avalanche | ステーキングの鍵と BLS の鍵のバックアップ | 最初のデプロイでそのホストで作った同じ鍵 |
| Sui バリデータ | 自分のマシンで作った protocol・network・worker の鍵 | 同じ 3 つの鍵（`systemd-creds` でそのホスト向けに暗号化）。アカウントの鍵は置きません |
| Sui フルノード | 台帳 | ネットワークの認証情報（そのホスト向けに暗号化）。ほかに写しはありません |
| TRON witness | 暗号化したキーストアとそのパスワード | 同じもの（暗号化した systemd の認証情報として） |
| Polygon バリデータ | `init` が生成する署名者の鍵。ステーキングのオーナーの鍵は求めません | 同じ鍵（そのホスト向けに暗号化）。監視だけをしている間、ノードは別のアイデンティティで動きます |
| BNB Chain バリデータ | 署名に使う素材とピアのアイデンティティのバックアップ | 暗号化したキーストアに入ったコンセンサスの鍵、暗号化したウォレットに入った投票の鍵、そのホスト向けに暗号化したそれぞれのパスワード |
| Kaia バリデータ（コンセンサスノードまたはプロキシノード） | ノードのアイデンティティのバックアップ | ホストで作り、そのホスト向けに暗号化したノードのアイデンティティ。運用者のウォレットは erpc の外に置いたままです |
| Monad ノード（RPC またはバリデータ） | 元のキーストアの両方 | 同じキーストア（そのホスト向けに暗号化） |
| Hyperliquid バリデータ | ホットのコンセンサスの鍵。コールドのアカウントの鍵は求めません | ホットの鍵（そのホスト向けに暗号化し、有効化したバリデータのユニットだけが読み込む） |
| Hyperliquid AQA パブリッシャー | 専用の API の鍵またはエージェントの鍵 | 同じ鍵（そのホスト向けに暗号化） |
| NEAR バリデータ | コンセンサスの鍵 | 同じ鍵（そのホスト向けに暗号化） |
| Arbitrum バリデータ | `init` が生成するウォレットと、プロバイダーの認証情報 | 暗号化したプロバイダーの認証情報と、`--activate-signer` 以降はウォレットも（root の所有で暗号化） |
| Robinhood Chain バリデータ | `init` が生成するウォレットと、プロバイダーの設定 | 暗号化したプロバイダーの設定と、`--activate-signer` 以降はウォレットも（root の所有で暗号化） |
| OP 系の RPC | 台帳とプロバイダーの値 | 暗号化したプロバイダーの認証情報、engine JWT、ピアのアイデンティティ。オーナーの記録とホストの暗号化のシークレットはバックアップしてください |
| Nitro RPC | 台帳と上流の認証情報 | 暗号化した上流の認証情報 |

ほかの RPC ノードはバリデータの署名鍵を持ちませんが、ホストにはクライアントが自分で作るもの（engine JWT、ピアのアイデンティティ、RPC の cookie など）が残ります。

鍵のバックアップだけでは、バリデータを安全に復旧できません。サーバーを入れ替えたりデータを復元したりする前に、そのチェーンの復旧手順に従ってください。鍵の復元の方法は各チェーンのガイドにあります（[ノード](https://erpc.global/ja/doc/erpc-cli/nodes/#対応チェーンとチェーンごとのガイド)）。

ノードの鍵を手元のマシンのディスクに書くコマンドが 1 つあります。`erpc validator vote-account` は、Solana CLI が動いている間、アイデンティティと投票の鍵を状態ディレクトリの下の `0600` のファイルに書き、終わったら消去します。プロセスが途中で落ちると、後の実行が片付けるまでファイルが残ることがあります。

`erpc worker` のアプリの取引用の鍵とシークレットは、これらとは別に置かれます。[鍵とシークレット](https://erpc.global/ja/doc/erpc-cli/worker-secrets/)を見てください。

## erpc が置くファイル

| パス | 中身 |
| --- | --- |
| `~/.erpc/config.toml` | 公開してよい設定（`erpc config`） |
| `~/.erpc/state/` | セッションとロック（セッションをどう保存しているかは `erpc doctor` が表示） |
| `~/.erpc/conversations/` | 保存した ERPC AI の会話 |
| `~/.erpc/memory.json` | ERPC AI が覚えていること |
| `~/.erpc/vps_hosts.json` | ERPC AI がログインした VPS のホスト鍵 |
| `~/.erpc/skills/` | `erpc skills install` が書いたスキル |
| `~/.erpc/storage-key` | ストレージの暗号化の鍵（`erpc login` がセッションをファイルに置くとき） |
| `~/.erpc/backup-password`、`~/.erpc/backup-admin-key` | バックアップのマスターパスワードと `read_write` の鍵（`erpc login` がセッションをファイルに置くとき） |
| `~/.erpc/keystore/` | ワーカーのキーストア。1Password も再起動の後まで残るキーチェーンもないマシンで、アプリのシークレットと取引用の鍵を、パスフレーズで暗号化したファイルに 1 つずつ置きます |
| `~/.erpc/workers.toml` | このマシンの `erpc worker` のアプリの一覧 |
| `~/.erpc/backup.env` | このマシンのバックアップの認証情報（`0600`） |
| `~/.erpc/bin/restic-0.19.1` | `erpc backup` がインストールする、版を固定した restic |