Sign in to ERPC CLI and see where your keys are kept

Sign this machine in, and ERPC CLI keeps the session in your keychain or 1Password. This page also shows where node keys are kept and which files erpc keeps.

This page describes ERPC CLI v0.1.0-rc.4, a pre-release.

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

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 gets the session through the OAuth device authorization grant. On a machine without a browser, erpc login --no-browser prints the URL and code instead of opening one, and erpc signup --no-browser prints the sign-up URL. erpc whoami shows who the stored session belongs to, and erpc logout signs out and removes the stored session.

At a terminal, erpc login asks which store to use: the operating system's keychain, which is the default, or 1Password when it answers. --store and --vault choose without asking, and the choice is recorded in config.toml, where the other commands read it.

Without a choice, given or recorded, erpc uses a 1Password service account when OP_SERVICE_ACCOUNT_TOKEN is set, else the operating system's keychain when there is one, else a file in its state directory. erpc doctor reports which store is in use and why. With a service account, erpc passes OP_SERVICE_ACCOUNT_TOKEN only to the op processes it starts, and does not write that token anywhere.

The 1Password item is titled with the machine's name, so that two machines never share one session. ERPC_HOST_LABEL overrides the name.

The keychain is the Secret Service where one answers. Otherwise it is the kernel's persistent keyring for your user, which is in memory and never on disk: the session lasts until a reboot or a few days unused, and then erpc login is asked for again. A shell started without a login of its own (su without -, sudo -E) cannot use that keyring, and erpc refuses and says so.

erpc reaches the keychain through /usr/bin/security. Any other program running as you can read the session by running security too, while the keychain still keeps the session encrypted at rest and away from other users.

erpc writes the session to its state directory in three cases: with the file store, for a parked session (a rotated refresh token that could not reach the store), and after an interrupted write. erpc doctor reports each such file for as long as it exists. On Unix these files are created with mode 0600; on Windows erpc sets no permissions of its own.

The node inventory, and the original-key backups each chain's guide names, are kept in 1Password. Not every key is in 1Password, and a node may hold a key it needs to run. Back up what is on a host yourself: rebuilding that host without a backup loses it. An active Sui validator or an elected TRON witness also refuses to move to a new host.

Other RPC nodes hold no signing key for a validator, but their hosts keep what the client makes for itself, such as an engine JWT, a peer identity or an RPC cookie.

A key backup alone does not make validator recovery safe. Follow the chain's recovery procedure before you replace a server or restore its data; each chain's guide says how to restore its keys (Nodes).

One command writes node keys to disk on your machine: erpc validator vote-account writes the identity and vote keys to 0600 files under the state directory while the Solana CLI runs, and wipes them afterwards. A process that dies can leave a file until a later run sweeps it.

An erpc worker app's trading key and secrets are kept apart from these: Keys and secrets.