---
title: "Inicia sesión en ERPC CLI y consulta dónde se guardan tus claves"
description: "Inicia sesión en tu cuenta de ERPC desde esta máquina, elige dónde guarda ERPC CLI la sesión y mira dónde están las claves de nodo y los archivos de erpc."
canonical: "https://erpc.global/es/doc/erpc-cli/sign-in-and-keys/"
locale: "es"
---

# Inicia sesión en ERPC CLI y consulta dónde se guardan tus claves

Inicia sesión en esta máquina y ERPC CLI guardará la sesión en tu llavero o en 1Password. Esta página también muestra dónde se guardan las claves de los nodos y qué archivos conserva erpc.

Esta página describe ERPC CLI `v0.1.0-rc.4`, una versión preliminar.

## Iniciar sesión

```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` obtiene la sesión mediante el OAuth device authorization grant. En una máquina sin navegador, `erpc login --no-browser` imprime la URL y el código en lugar de abrir un navegador, y `erpc signup --no-browser` imprime la URL de registro. `erpc whoami` muestra a quién pertenece la sesión guardada, y `erpc logout` cierra la sesión y elimina la sesión guardada.

## Elegir dónde se guarda la sesión

En un terminal, `erpc login` pregunta qué almacén usar: el llavero del sistema operativo, que es la opción predeterminada, o 1Password cuando responde. `--store` y `--vault` eligen sin preguntar, y la elección queda registrada en `config.toml`, donde la leen los demás comandos.

| `--store` | Dónde se guarda la sesión |
| --- | --- |
| `keychain` | El llavero del sistema operativo |
| `1password-desktop` (también `1password`, `op`) | 1Password, a través de la aplicación de escritorio |
| `1password-service-account` | 1Password, a través de un token de cuenta de servicio |
| `file` | Un archivo en disco. Esto deja un secreto en esta máquina |

Si no hay ninguna elección, ni indicada ni registrada, erpc usa una cuenta de servicio de 1Password cuando `OP_SERVICE_ACCOUNT_TOKEN` está definida; si no, el llavero del sistema operativo cuando lo hay; y si no, un archivo en su directorio de estado. `erpc doctor` indica qué almacén está en uso y por qué. Con una cuenta de servicio, erpc pasa `OP_SERVICE_ACCOUNT_TOKEN` solo a los procesos `op` que inicia, y no escribe ese token en ningún sitio.

El elemento de 1Password lleva como título el nombre de la máquina, para que dos máquinas nunca compartan una misma sesión. `ERPC_HOST_LABEL` sustituye ese nombre.

### En Linux

El llavero es el Secret Service cuando hay uno que responda. Si no, es el keyring persistente del kernel para tu usuario, que está en memoria y nunca en disco: la sesión dura hasta un reinicio o unos pocos días sin uso, y después se vuelve a pedir `erpc login`. Un shell iniciado sin un inicio de sesión propio (`su` sin `-`, `sudo -E`) no puede usar ese keyring, y erpc se niega y lo indica.

### En macOS

erpc accede al llavero a través de `/usr/bin/security`. Cualquier otro programa que se ejecute con tu usuario puede leer la sesión ejecutando también `security`, aunque el llavero sigue manteniendo la sesión cifrada en reposo y fuera del alcance de otros usuarios.

### Cuando la sesión está en disco

erpc escribe la sesión en su directorio de estado en tres casos: con el almacén `file`, para una sesión aparcada (un refresh token rotado que no pudo llegar al almacén) y tras una escritura interrumpida. `erpc doctor` informa de cada uno de esos archivos mientras exista. En Unix, estos archivos se crean con el modo `0600`; en Windows, erpc no establece permisos propios.

## Dónde se guardan las claves de los nodos

El inventario de nodos, y las copias de seguridad de las claves originales que indica la guía de cada cadena, se guardan en 1Password. No todas las claves están en 1Password, y un nodo puede contener una clave que necesita para funcionar. Haz tú mismo una copia de seguridad de lo que hay en un host: si reconstruyes ese host sin copia de seguridad, lo pierdes. Además, un validador de Sui activo o un witness de TRON elegido se niega a moverse a un host nuevo.

| Nodo | En 1Password | En el host |
| --- | --- | --- |
| Validador de Solana (nativo) | La identidad y el keypair de sincronización que creaste. La cuenta de voto y la autoridad de retiro se dan a erpc solo como claves públicas | El keypair de sincronización, cifrado para ese host, y a partir de `--activate-validator` también la identidad. Las claves de la cuenta de voto y de retiro nunca se importan |
| Validador de Solana (solv) | La identidad con stake, y la autoridad de retiro salvo que des solo su clave pública. La clave de la cuenta de voto se borra una vez verificada la cuenta | Un `unstaked-identity.json` desechable en texto plano. Un despliegue nunca copia al nodo la clave con stake ni la autoridad de retiro |
| RPC de Solana (nativo) | La identidad que creaste | La misma identidad, cifrada para ese host |
| RPC de Solana (solv) | El inventario | La identidad, creada allí. Nunca sale de allí |
| Validador de Ethereum | El inventario | Los keystores, su contraseña de desbloqueo y el historial de slashing. El historial de una copia de seguridad se detiene en su instantánea, así que restaurar una clave que firmó después de ella puede provocar slashing: mueve un firmante con `erpc v --chain eth migrate` |
| RPC de Arc | La clave de consenso | La clave de consenso, cifrada |
| Avalanche | Una copia de seguridad de las claves de staking y BLS | Las mismas claves, creadas allí en el primer despliegue |
| Validador de Sui | Las claves de protocolo, de red y de worker, creadas en tu propia máquina | Las mismas tres claves, cifradas con `systemd-creds` para ese host. Nunca la clave de la cuenta |
| Nodo completo de Sui | El inventario | La credencial de red, cifrada para ese host. No hay ninguna otra copia |
| Witness de TRON | El keystore cifrado y su contraseña | Lo mismo, como credenciales de systemd cifradas |
| Validador de Polygon | La clave del firmante que genera `init`. Nunca se pide la clave del propietario del staking | La misma clave, cifrada para ese host. Mientras solo observa, el nodo se ejecuta con una identidad distinta |
| Validador de BNB Chain | Una copia de seguridad del material de firma y de la identidad de peer | La clave de consenso en un keystore cifrado, la clave de voto en una wallet cifrada, y sus contraseñas cifradas para ese host |
| Validador de Kaia (nodo de consenso o proxy) | Una copia de seguridad de la identidad del nodo | La identidad del nodo, creada en el host y cifrada para él. Las wallets del operador quedan fuera de erpc |
| Nodo de Monad (RPC o validador) | Los dos keystores originales | Los mismos keystores, cifrados para ese host |
| Validador de Hyperliquid | La clave de consenso hot. Nunca se pide la clave de la cuenta cold | La clave hot, cifrada para ese host y cargada solo por las unidades de validador activadas |
| Publicador AQA de Hyperliquid | Su clave de API o de agente dedicada | La misma clave, cifrada para ese host |
| Validador de NEAR | La clave de consenso | La misma clave, cifrada para ese host |
| Validador de Arbitrum | La wallet que genera `init`, y la credencial del proveedor | La credencial del proveedor, cifrada, y a partir de `--activate-signer` también la wallet, propiedad de root y cifrada |
| Validador de Robinhood Chain | La wallet que genera `init`, y la configuración del proveedor | La configuración del proveedor, cifrada, y a partir de `--activate-signer` también la wallet, propiedad de root y cifrada |
| RPC de la familia OP | El inventario y los valores del proveedor | La credencial del proveedor, el JWT del engine y las identidades de peer, cifrados. Haz una copia de seguridad del registro del propietario y del secreto de cifrado del host |
| RPC de Nitro | El inventario y la credencial del upstream | La credencial del upstream, cifrada |

Los demás nodos RPC no contienen ninguna clave de firma de un validador, pero sus hosts conservan lo que el cliente crea para sí mismo, como un JWT del engine, una identidad de peer o una cookie de RPC.

Una copia de seguridad de las claves no basta por sí sola para que recuperar un validador sea seguro. Sigue el procedimiento de recuperación de la cadena antes de sustituir un servidor o restaurar sus datos; la guía de cada cadena explica cómo restaurar sus claves ([Nodos](https://erpc.global/es/doc/erpc-cli/nodes/#cadenas-y-guías)).

Un solo comando escribe claves de nodo en el disco de tu máquina: `erpc validator vote-account` escribe las claves de identidad y de voto en archivos `0600` dentro del directorio de estado mientras se ejecuta la Solana CLI, y las borra después. Un proceso que muere puede dejar un archivo hasta que una ejecución posterior lo elimine.

La clave de trading y los secretos de una aplicación de `erpc worker` se guardan aparte de estas: [Claves y secretos](https://erpc.global/es/doc/erpc-cli/worker-secrets/).

## Archivos que conserva erpc

| Ruta | Qué contiene |
| --- | --- |
| `~/.erpc/config.toml` | Ajustes públicos (`erpc config`) |
| `~/.erpc/state/` | La sesión y los bloqueos (`erpc doctor` indica cómo se guarda la sesión) |
| `~/.erpc/conversations/` | Conversaciones guardadas de ERPC AI |
| `~/.erpc/memory.json` | Lo que ERPC AI recuerda |
| `~/.erpc/vps_hosts.json` | Claves de host de los VPS en los que ERPC AI ha iniciado sesión |
| `~/.erpc/skills/` | Skills escritas por `erpc skills install` |
| `~/.erpc/storage-key` | La clave de cifrado del almacenamiento, cuando `erpc login` guarda la sesión en un archivo |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | La contraseña maestra de las copias de seguridad y la clave `read_write`, cuando `erpc login` guarda la sesión en un archivo |
| `~/.erpc/keystore/` | El keystore del worker: los secretos y la clave de trading de una aplicación, cada uno en un archivo cifrado con tu frase de contraseña, en una máquina sin 1Password ni un llavero que perdure |
| `~/.erpc/workers.toml` | La lista de aplicaciones de `erpc worker` en esta máquina |
| `~/.erpc/backup.env` | Las credenciales de copia de seguridad de esta máquina (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | La versión fijada de restic que instala `erpc backup` |