---
title: "Faça login no ERPC CLI e veja onde suas chaves ficam guardadas"
description: "Faça login na sua conta ERPC nesta máquina, escolha onde o ERPC CLI guarda a sessão e veja onde ficam as chaves dos nós e os arquivos que o erpc grava."
canonical: "https://erpc.global/pt/doc/erpc-cli/sign-in-and-keys/"
locale: "pt"
---

# Faça login no ERPC CLI e veja onde suas chaves ficam guardadas

Faça login nesta máquina, e o ERPC CLI guarda a sessão no seu chaveiro ou no 1Password. Esta página também mostra onde ficam as chaves dos nós e quais arquivos o erpc mantém.

Esta página descreve o ERPC CLI `v0.1.0-rc.4`, uma versão de pré-lançamento.

## Fazer login

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

O `erpc login` obtém a sessão pelo OAuth device authorization grant. Em uma máquina sem navegador, `erpc login --no-browser` imprime a URL e o código em vez de abrir um navegador, e `erpc signup --no-browser` imprime a URL de cadastro. O `erpc whoami` mostra a quem pertence a sessão armazenada, e o `erpc logout` faz logout e remove a sessão armazenada.

## Escolher onde a sessão fica guardada

Em um terminal, o `erpc login` pergunta em que local guardar a sessão: o chaveiro do sistema operacional, que é o padrão, ou o 1Password, quando ele responde. `--store` e `--vault` fazem a escolha sem perguntar, e a escolha é registrada no `config.toml`, onde os outros comandos a leem.

| `--store` | Onde a sessão fica guardada |
| --- | --- |
| `keychain` | O chaveiro do sistema operacional |
| `1password-desktop` (também `1password`, `op`) | 1Password, pelo aplicativo de desktop |
| `1password-service-account` | 1Password, por um token de conta de serviço |
| `file` | Um arquivo em disco. Isso deixa um segredo nesta máquina |

Sem uma escolha, informada ou registrada, o erpc usa uma conta de serviço do 1Password quando `OP_SERVICE_ACCOUNT_TOKEN` está definido; caso contrário, o chaveiro do sistema operacional, quando houver um; e, caso contrário, um arquivo no diretório de estado dele. O `erpc doctor` informa qual local está em uso e por quê. Com uma conta de serviço, o erpc passa `OP_SERVICE_ACCOUNT_TOKEN` somente para os processos `op` que ele inicia, e não grava esse token em lugar nenhum.

O item do 1Password recebe como título o nome da máquina, para que duas máquinas nunca compartilhem uma mesma sessão. `ERPC_HOST_LABEL` substitui esse nome.

### No Linux

O chaveiro é o Secret Service, onde houver um que responda. Caso contrário, é o keyring persistente do kernel para o seu usuário, que fica na memória e nunca em disco: a sessão dura até uma reinicialização ou alguns dias sem uso, e então o `erpc login` é pedido novamente. Um shell iniciado sem um login próprio (`su` sem `-`, `sudo -E`) não consegue usar esse keyring, e o erpc recusa e informa isso.

### No macOS

O erpc acessa o chaveiro por meio de `/usr/bin/security`. Qualquer outro programa executado como você pode ler a sessão executando também o `security`, enquanto o chaveiro continua mantendo a sessão criptografada em repouso e fora do alcance de outros usuários.

### Quando a sessão fica em disco

O erpc grava a sessão no diretório de estado dele em três casos: com o local `file`, para uma sessão estacionada (um refresh token rotacionado que não conseguiu chegar ao local de armazenamento) e após uma gravação interrompida. O `erpc doctor` informa cada um desses arquivos enquanto ele existir. No Unix, esses arquivos são criados com o modo `0600`; no Windows, o erpc não define permissões próprias.

## Onde ficam as chaves dos nós

O inventário de nós e os backups das chaves originais indicados no guia de cada chain ficam no 1Password. Nem toda chave está no 1Password, e um nó pode manter uma chave de que precisa para funcionar. Faça você mesmo o backup do que está em um host: reconstruir esse host sem um backup faz com que esse conteúdo se perca. Um validador Sui ativo ou uma witness TRON eleita também se recusa a mudar para um novo host.

| Nó | No 1Password | No host |
| --- | --- | --- |
| Validador Solana (nativo) | A identidade e o keypair de sincronização que você criou. A vote account e a withdraw authority são passadas ao erpc somente como chaves públicas | O keypair de sincronização, criptografado para esse host, e, a partir de `--activate-validator`, também a identidade. As chaves da vote account e de saque nunca são importadas |
| Validador Solana (solv) | A identidade com stake e a withdraw authority, a menos que você informe apenas a chave pública dela. A chave da vote account é excluída assim que a conta é verificada | Um `unstaked-identity.json` descartável em texto puro. Uma implantação nunca copia a chave com stake nem a withdraw authority para o nó |
| RPC Solana (nativo) | A identidade que você criou | A mesma identidade, criptografada para esse host |
| RPC Solana (solv) | O inventário | A identidade, criada lá. Ela nunca sai de lá |
| Validador Ethereum | O inventário | Os keystores, a senha que os desbloqueia e o histórico de slashing. O histórico de um backup termina no snapshot dele, então restaurar uma chave que assinou depois disso pode causar slashing: mova um signer com `erpc v --chain eth migrate` |
| RPC Arc | A chave de consenso | A chave de consenso, criptografada |
| Avalanche | Um backup das chaves de staking e BLS | As mesmas chaves, criadas lá na primeira implantação |
| Validador Sui | As chaves de protocolo, de rede e de worker, criadas na sua própria máquina | As mesmas três chaves, criptografadas com `systemd-creds` para esse host. Nunca a chave da conta |
| Full node Sui | O inventário | A credencial de rede, criptografada para esse host. Não existe outra cópia |
| Witness TRON | O keystore criptografado e a senha dele | O mesmo, como credenciais systemd criptografadas |
| Validador Polygon | A chave do signer que o `init` gera. A chave do proprietário do staking nunca é solicitada | A mesma chave, criptografada para esse host. Enquanto o nó apenas observa, ele roda com uma identidade separada |
| Validador BNB Chain | Um backup do material de assinatura e da identidade de peer | A chave de consenso em um keystore criptografado, a chave de voto em uma wallet criptografada e as senhas delas criptografadas para esse host |
| Validador Kaia (nó de consenso ou proxy) | Um backup da identidade do nó | A identidade do nó, criada no host e criptografada para ele. As wallets do operador ficam fora do erpc |
| Nó Monad (RPC ou validador) | Os dois keystores originais | Os mesmos keystores, criptografados para esse host |
| Validador Hyperliquid | A chave hot de consenso. A chave da conta cold nunca é solicitada | A chave hot, criptografada para esse host e carregada somente pelas unidades de validador ativadas |
| Publicador AQA Hyperliquid | A API key ou chave de agente dedicada dele | A mesma chave, criptografada para esse host |
| Validador NEAR | A chave de consenso | A mesma chave, criptografada para esse host |
| Validador Arbitrum | A wallet que o `init` gera e a credencial do provedor | A credencial do provedor, criptografada, e, a partir de `--activate-signer`, também a wallet, de propriedade do root e criptografada |
| Validador Robinhood Chain | A wallet que o `init` gera e a configuração do provedor | A configuração do provedor, criptografada, e, a partir de `--activate-signer`, também a wallet, de propriedade do root e criptografada |
| RPC da família OP | O inventário e os valores do provedor | A credencial do provedor, o JWT do engine e as identidades de peer, criptografados. Faça backup do registro do proprietário e do segredo de criptografia do host |
| RPC Nitro | O inventário e a credencial upstream | A credencial upstream, criptografada |

Os outros nós RPC não mantêm nenhuma chave de assinatura de validador, mas os hosts deles guardam o que o cliente cria para si mesmo, como um JWT do engine, uma identidade de peer ou um cookie RPC.

Um backup de chave, por si só, não torna segura a recuperação de um validador. Siga o procedimento de recuperação da chain antes de substituir um servidor ou restaurar os dados dele; o guia de cada chain explica como restaurar as chaves dela ([Nós](https://erpc.global/pt/doc/erpc-cli/nodes/#chains-e-guias)).

Apenas um comando grava chaves de nó em disco na sua máquina: `erpc validator vote-account` grava as chaves de identidade e de voto em arquivos `0600` dentro do diretório de estado enquanto a Solana CLI é executada, e as apaga depois. Um processo que morre pode deixar um arquivo até que uma execução posterior o remova.

A chave de trading e os segredos de uma aplicação do `erpc worker` ficam separados destas: [Chaves e segredos](https://erpc.global/pt/doc/erpc-cli/worker-secrets/).

## Arquivos que o erpc mantém

| Caminho | O que contém |
| --- | --- |
| `~/.erpc/config.toml` | Configurações públicas (`erpc config`) |
| `~/.erpc/state/` | A sessão e os bloqueios (o `erpc doctor` informa como a sessão está armazenada) |
| `~/.erpc/conversations/` | Conversas salvas do ERPC AI |
| `~/.erpc/memory.json` | O que o ERPC AI lembra |
| `~/.erpc/vps_hosts.json` | Chaves de host das VPSs em que o ERPC AI fez login |
| `~/.erpc/skills/` | Skills gravadas pelo `erpc skills install` |
| `~/.erpc/storage-key` | A chave de criptografia do armazenamento, quando o `erpc login` guarda a sessão em um arquivo |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | A senha mestra de backup e a chave `read_write`, quando o `erpc login` guarda a sessão em um arquivo |
| `~/.erpc/keystore/` | O keystore do worker: os segredos e a chave de trading de uma aplicação, cada um em um arquivo criptografado com a sua frase-senha, em uma máquina sem 1Password e sem um chaveiro que persista |
| `~/.erpc/workers.toml` | A lista de aplicações do `erpc worker` nesta máquina |
| `~/.erpc/backup.env` | As credenciais de backup desta máquina (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | O restic fixado que o `erpc backup` instala |