---
title: "Войдите в ERPC CLI и узнайте, где хранятся ваши ключи"
description: "Выполните вход в аккаунт ERPC на этой машине, выберите, где ERPC CLI хранит сессию, и узнайте, где хранятся ключи нод и файлы, которые записывает erpc."
canonical: "https://erpc.global/ru/doc/erpc-cli/sign-in-and-keys/"
locale: "ru"
---

# Войдите в 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` спрашивает, какое место хранения использовать: связку ключей операционной системы (по умолчанию) или 1Password, если он отвечает. `--store` и `--vault` задают выбор без вопросов, и этот выбор записывается в `config.toml`, откуда его читают остальные команды.

| `--store` | Где хранится сессия |
| --- | --- |
| `keychain` | В связке ключей операционной системы |
| `1password-desktop` (также `1password`, `op`) | В 1Password, через настольное приложение |
| `1password-service-account` | В 1Password, через токен сервисного аккаунта |
| `file` | В файле на диске. При этом на этой машине остаётся секрет |

Если выбор не задан и не записан, erpc использует сервисный аккаунт 1Password, когда задана `OP_SERVICE_ACCOUNT_TOKEN`, иначе связку ключей операционной системы, если она есть, иначе файл в своём каталоге состояния. `erpc doctor` сообщает, какое место хранения используется и почему. При работе с сервисным аккаунтом erpc передаёт `OP_SERVICE_ACCOUNT_TOKEN` только процессам `op`, которые сам запускает, и нигде этот токен не записывает.

Элемент 1Password называется по имени машины, чтобы две машины никогда не делили одну сессию. `ERPC_HOST_LABEL` переопределяет это имя.

### В Linux

Связка ключей — это Secret Service, если он отвечает. В противном случае это постоянный keyring ядра для вашего пользователя, который находится в памяти и никогда не попадает на диск: сессия действует до перезагрузки или нескольких дней без использования, после чего снова потребуется `erpc login`. Оболочка, запущенная без собственного входа (`su` без `-`, `sudo -E`), не может использовать этот keyring, и erpc отказывается работать и сообщает об этом.

### В macOS

erpc обращается к связке ключей через `/usr/bin/security`. Любая другая программа, запущенная от вашего имени, может прочитать сессию, тоже вызвав `security`, при этом связка ключей по-прежнему хранит сессию зашифрованной на диске и недоступной для других пользователей.

### Когда сессия хранится на диске

erpc записывает сессию в свой каталог состояния в трёх случаях: при использовании места хранения `file`, для отложенной сессии (refresh-токена после ротации, который не удалось передать в место хранения) и после прерванной записи. `erpc doctor` сообщает о каждом таком файле, пока он существует. В Unix эти файлы создаются с режимом `0600`; в Windows erpc не задаёт собственных прав доступа.

## Где хранятся ключи нод

Реестр нод и резервные копии исходных ключей, которые указаны в руководстве по каждому блокчейну, хранятся в 1Password. Не каждый ключ находится в 1Password, и нода может хранить ключ, который нужен ей для работы. Резервную копию того, что находится на хосте, делайте сами: если пересобрать хост без резервной копии, это будет потеряно. Кроме того, активный валидатор Sui или избранный witness TRON отказывается переезжать на новый хост.

| Нода | В 1Password | На хосте |
| --- | --- | --- |
| Валидатор Solana (native) | Identity и созданный вами sync keypair. Vote account и withdraw authority передаются erpc только как открытые ключи | Sync keypair, зашифрованный для этого хоста, а начиная с `--activate-validator` — также identity. Ключи vote account и withdrawal никогда не импортируются |
| Валидатор Solana (solv) | Застейканный identity, а также withdraw authority, если вы не передали только его открытый ключ. Ключ vote account удаляется, как только аккаунт будет проверен | Одноразовый `unstaked-identity.json` в открытом виде. Развёртывание никогда не копирует на ноду застейканный ключ или withdraw authority |
| Solana RPC (native) | Созданный вами identity | Тот же identity, зашифрованный для этого хоста |
| Solana RPC (solv) | Реестр | Identity, созданный там же. Он никогда не покидает хост |
| Валидатор Ethereum | Реестр | Keystore-файлы, пароль для их разблокировки и история slashing. История в резервной копии заканчивается на её снимке, поэтому восстановление ключа, который подписывал после него, может привести к slashing: переносите подписанта с помощью `erpc v --chain eth migrate` |
| Arc RPC | Консенсусный ключ | Консенсусный ключ в зашифрованном виде |
| Avalanche | Резервная копия ключей staking и BLS | Те же ключи, созданные там же при первом развёртывании |
| Валидатор Sui | Ключи protocol, network и worker, созданные на вашей собственной машине | Те же три ключа, зашифрованные с помощью `systemd-creds` для этого хоста. Ключ аккаунта — никогда |
| Полная нода Sui | Реестр | Сетевые учётные данные, зашифрованные для этого хоста. Другой копии нет |
| Witness TRON | Зашифрованный keystore и его пароль | То же самое, в виде зашифрованных учётных данных systemd |
| Валидатор Polygon | Ключ подписанта, который генерирует `init`. Ключ владельца стейка никогда не запрашивается | Тот же ключ, зашифрованный для этого хоста. Пока нода только наблюдает, она работает под отдельным identity |
| Валидатор BNB Chain | Резервная копия материала для подписи и peer identity | Консенсусный ключ в зашифрованном keystore, ключ голосования в зашифрованном кошельке и их пароли, зашифрованные для этого хоста |
| Валидатор Kaia (консенсусная или прокси-нода) | Резервная копия identity ноды | Identity ноды, созданный на хосте и зашифрованный для него. Кошельки оператора остаются вне erpc |
| Нода Monad (RPC или валидатор) | Оба исходных keystore | Те же keystore, зашифрованные для этого хоста |
| Валидатор Hyperliquid | Горячий консенсусный ключ. Ключ холодного аккаунта никогда не запрашивается | Горячий ключ, зашифрованный для этого хоста и загружаемый только активированными юнитами валидатора |
| Hyperliquid AQA publisher | Его выделенный API-ключ или ключ агента | Тот же ключ, зашифрованный для этого хоста |
| Валидатор NEAR | Консенсусный ключ | Тот же ключ, зашифрованный для этого хоста |
| Валидатор Arbitrum | Кошелёк, который генерирует `init`, и учётные данные провайдера | Учётные данные провайдера в зашифрованном виде, а начиная с `--activate-signer` — также кошелёк, принадлежащий root и зашифрованный |
| Валидатор Robinhood Chain | Кошелёк, который генерирует `init`, и конфигурация провайдера | Конфигурация провайдера в зашифрованном виде, а начиная с `--activate-signer` — также кошелёк, принадлежащий root и зашифрованный |
| RPC семейства OP | Реестр и значения провайдера | Учётные данные провайдера, JWT движка и peer identity в зашифрованном виде. Сделайте резервную копию записи владельца и секрета шифрования хоста |
| Nitro RPC | Реестр и учётные данные upstream | Учётные данные upstream в зашифрованном виде |

Другие RPC-ноды не хранят ключа подписи для валидатора, но на их хостах остаётся то, что клиент создаёт для себя, например JWT движка, peer identity или RPC cookie.

Одна лишь резервная копия ключа не делает восстановление валидатора безопасным. Прежде чем заменять сервер или восстанавливать его данные, выполните процедуру восстановления для этого блокчейна; в руководстве по каждому блокчейну описано, как восстановить его ключи ([Ноды](https://erpc.global/ru/doc/erpc-cli/nodes/#блокчейны-и-руководства)).

Только одна команда записывает ключи нод на диск вашей машины: `erpc validator vote-account` записывает ключи identity и vote в файлы с режимом `0600` в каталоге состояния, пока работает Solana CLI, и затем стирает их. Если процесс аварийно завершится, файл может остаться, пока его не удалит один из следующих запусков.

Торговый ключ и секреты приложения `erpc worker` хранятся отдельно от них: [Ключи и секреты](https://erpc.global/ru/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` | Ключи хостов VPS, на которые входил ERPC AI |
| `~/.erpc/skills/` | Навыки, записанные командой `erpc skills install` |
| `~/.erpc/storage-key` | Ключ шифрования хранилища, если `erpc login` хранит сессию в файле |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | Мастер-пароль резервного копирования и ключ `read_write`, если `erpc login` хранит сессию в файле |
| `~/.erpc/keystore/` | Keystore воркеров: секреты и торговый ключ приложения, каждый в файле, зашифрованном вашей парольной фразой, — на машине, где нет ни 1Password, ни долговременной связки ключей |
| `~/.erpc/workers.toml` | Список приложений `erpc worker` на этой машине |
| `~/.erpc/backup.env` | Учётные данные резервного копирования этой машины (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | Зафиксированная версия restic, которую устанавливает `erpc backup` |