---
title: "Accedi a ERPC CLI e vedi dove vengono conservate le tue chiavi"
description: "Accedi al tuo account ERPC da questa macchina, scegli dove ERPC CLI conserva la sessione e vedi dove sono le chiavi dei nodi e i file scritti da erpc."
canonical: "https://erpc.global/it/doc/erpc-cli/sign-in-and-keys/"
locale: "it"
---

# Accedi a ERPC CLI e vedi dove vengono conservate le tue chiavi

Accedi da questa macchina, ed ERPC CLI conserva la sessione nel tuo portachiavi o in 1Password. Questa pagina mostra anche dove vengono conservate le chiavi dei nodi e quali file conserva erpc.

Questa pagina descrive ERPC CLI `v0.1.0-rc.4`, una versione pre-release.

## Accedere

```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` ottiene la sessione tramite l'OAuth device authorization grant. Su una macchina senza browser, `erpc login --no-browser` stampa l'URL e il codice invece di aprire un browser, ed `erpc signup --no-browser` stampa l'URL di iscrizione. `erpc whoami` mostra a chi appartiene la sessione memorizzata, ed `erpc logout` esegue la disconnessione e rimuove la sessione memorizzata.

## Scegliere dove viene conservata la sessione

Da un terminale, `erpc login` chiede quale archivio usare: il portachiavi del sistema operativo, che è l'opzione predefinita, oppure 1Password quando risponde. `--store` e `--vault` scelgono senza chiedere, e la scelta viene registrata in `config.toml`, dove la leggono gli altri comandi.

| `--store` | Dove viene conservata la sessione |
| --- | --- |
| `keychain` | Il portachiavi del sistema operativo |
| `1password-desktop` (anche `1password`, `op`) | 1Password, tramite l'applicazione desktop |
| `1password-service-account` | 1Password, tramite il token di un account di servizio |
| `file` | Un file su disco. Lascia un secret su questa macchina |

Senza una scelta, indicata o registrata, erpc usa un account di servizio 1Password quando `OP_SERVICE_ACCOUNT_TOKEN` è impostato, altrimenti il portachiavi del sistema operativo quando ce n'è uno, altrimenti un file nella sua directory di stato. `erpc doctor` indica quale archivio è in uso e perché. Con un account di servizio, erpc passa `OP_SERVICE_ACCOUNT_TOKEN` solo ai processi `op` che avvia, e non scrive quel token da nessuna parte.

L'elemento di 1Password prende come titolo il nome della macchina, così due macchine non condividono mai una stessa sessione. `ERPC_HOST_LABEL` sostituisce il nome.

### Su Linux

Il portachiavi è il Secret Service, dove ce n'è uno che risponde. Altrimenti è il keyring persistente del kernel per il tuo utente, che sta in memoria e mai su disco: la sessione dura fino a un riavvio o a qualche giorno di inutilizzo, dopodiché viene richiesto di nuovo `erpc login`. Una shell avviata senza un proprio login (`su` senza `-`, `sudo -E`) non può usare quel keyring, ed erpc si rifiuta e lo segnala.

### Su macOS

erpc raggiunge il portachiavi tramite `/usr/bin/security`. Qualsiasi altro programma eseguito con il tuo utente può leggere la sessione eseguendo anch'esso `security`, mentre il portachiavi mantiene comunque la sessione cifrata a riposo e fuori dalla portata degli altri utenti.

### Quando la sessione è su disco

erpc scrive la sessione nella sua directory di stato in tre casi: con l'archivio `file`, per una sessione parcheggiata (un refresh token ruotato che non è riuscito a raggiungere l'archivio) e dopo una scrittura interrotta. `erpc doctor` segnala ciascuno di questi file finché esiste. Su Unix questi file vengono creati con modalità `0600`; su Windows erpc non imposta permessi propri.

## Dove vengono conservate le chiavi dei nodi

L'inventario dei nodi, e i backup delle chiavi originali indicati dalla guida di ogni chain, sono conservati in 1Password. Non tutte le chiavi sono in 1Password, e un nodo può contenere una chiave di cui ha bisogno per funzionare. Fai tu il backup di ciò che si trova su un host: ricostruire quell'host senza un backup significa perderlo. Inoltre, un validator Sui attivo o un witness TRON eletto si rifiuta di spostarsi su un nuovo host.

| Nodo | In 1Password | Sull'host |
| --- | --- | --- |
| Validator Solana (native) | L'identity e il sync keypair che hai creato. Il vote account e la withdraw authority vengono forniti a erpc solo come chiavi pubbliche | Il sync keypair, cifrato per quell'host, e da `--activate-validator` in poi anche l'identity. Le chiavi del vote account e di prelievo non vengono mai importate |
| Validator Solana (solv) | L'identity in stake, e la withdraw authority a meno che tu non ne fornisca solo la chiave pubblica. La chiave del vote account viene eliminata una volta verificato l'account | Un `unstaked-identity.json` usa e getta in chiaro. Una distribuzione non copia mai sul nodo la chiave in stake né la withdraw authority |
| RPC Solana (native) | L'identity che hai creato | La stessa identity, cifrata per quell'host |
| RPC Solana (solv) | L'inventario | L'identity, creata lì. Non lascia mai l'host |
| Validator Ethereum | L'inventario | I keystore, la loro password di sblocco e lo storico di slashing. Lo storico di un backup si ferma al suo snapshot, quindi ripristinare una chiave che ha firmato dopo di esso può causare uno slashing: sposta un signer con `erpc v --chain eth migrate` |
| RPC Arc | La chiave di consenso | La chiave di consenso, cifrata |
| Avalanche | Un backup delle chiavi di staking e BLS | Le stesse chiavi, create lì alla prima distribuzione |
| Validator Sui | Le chiavi di protocollo, di rete e del worker, create sulla tua macchina | Le stesse tre chiavi, cifrate con `systemd-creds` per quell'host. Mai la chiave dell'account |
| Full node Sui | L'inventario | La credenziale di rete, cifrata per quell'host. Non ne esiste un'altra copia |
| Witness TRON | Il keystore cifrato e la sua password | Gli stessi, come credenziali systemd cifrate |
| Validator Polygon | La chiave del signer generata da `init`. La chiave del proprietario dello staking non viene mai richiesta | La stessa chiave, cifrata per quell'host. Finché si limita a osservare, il nodo gira con un'identità separata |
| Validator BNB Chain | Un backup del materiale di firma e dell'identità di peer | La chiave di consenso in un keystore cifrato, la chiave di voto in un wallet cifrato e le loro password cifrate per quell'host |
| Validator Kaia (nodo di consenso o proxy) | Un backup dell'identità del nodo | L'identità del nodo, creata sull'host e cifrata per esso. I wallet dell'operatore restano fuori da erpc |
| Nodo Monad (RPC o validator) | Entrambi i keystore originali | Gli stessi keystore, cifrati per quell'host |
| Validator Hyperliquid | La chiave di consenso hot. La chiave dell'account cold non viene mai richiesta | La chiave hot, cifrata per quell'host e caricata solo dalle unità del validator attivate |
| Publisher AQA Hyperliquid | La sua chiave API o chiave agente dedicata | La stessa chiave, cifrata per quell'host |
| Validator NEAR | La chiave di consenso | La stessa chiave, cifrata per quell'host |
| Validator Arbitrum | Il wallet generato da `init` e la credenziale del provider | La credenziale del provider, cifrata, e da `--activate-signer` in poi anche il wallet, di proprietà di root e cifrato |
| Validator Robinhood Chain | Il wallet generato da `init` e la configurazione del provider | La configurazione del provider, cifrata, e da `--activate-signer` in poi anche il wallet, di proprietà di root e cifrato |
| RPC della famiglia OP | L'inventario e i valori del provider | Credenziale del provider, JWT dell'engine e identità di peer, cifrati. Fai il backup del record del proprietario e del secret di cifratura dell'host |
| RPC Nitro | L'inventario e la credenziale upstream | La credenziale upstream, cifrata |

Gli altri nodi RPC non contengono alcuna chiave di firma per un validator, ma i loro host conservano ciò che il client crea per sé, come un JWT dell'engine, un'identità di peer o un cookie RPC.

Un backup delle chiavi da solo non rende sicuro il ripristino di un validator. Segui la procedura di ripristino della chain prima di sostituire un server o di ripristinarne i dati; la guida di ogni chain spiega come ripristinarne le chiavi ([Nodi](https://erpc.global/it/doc/erpc-cli/nodes/#chain-e-guide)).

Un solo comando scrive chiavi dei nodi su disco sulla tua macchina: `erpc validator vote-account` scrive le chiavi dell'identity e di voto in file `0600` nella directory di stato mentre è in esecuzione la Solana CLI, e poi le cancella. Un processo che termina in modo anomalo può lasciare un file finché un'esecuzione successiva non lo rimuove.

La chiave di trading e i secret di un'app `erpc worker` sono conservati separatamente da queste: [Chiavi e secret](https://erpc.global/it/doc/erpc-cli/worker-secrets/).

## File conservati da erpc

| Percorso | Cosa contiene |
| --- | --- |
| `~/.erpc/config.toml` | Impostazioni pubbliche (`erpc config`) |
| `~/.erpc/state/` | La sessione e i lock (`erpc doctor` indica come è memorizzata la sessione) |
| `~/.erpc/conversations/` | Le conversazioni salvate di ERPC AI |
| `~/.erpc/memory.json` | Ciò che ERPC AI ricorda |
| `~/.erpc/vps_hosts.json` | Le chiavi host dei VPS a cui ERPC AI ha effettuato l'accesso |
| `~/.erpc/skills/` | Le skill scritte da `erpc skills install` |
| `~/.erpc/storage-key` | La chiave di cifratura dello storage, quando `erpc login` conserva la sessione in un file |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | La password master dei backup e la chiave `read_write`, quando `erpc login` conserva la sessione in un file |
| `~/.erpc/keystore/` | Il keystore del worker: i secret e la chiave di trading di un'app, ciascuno in un file cifrato con la tua passphrase, su una macchina che non ha né 1Password né un portachiavi persistente |
| `~/.erpc/workers.toml` | L'elenco delle app `erpc worker` su questa macchina |
| `~/.erpc/backup.env` | Le credenziali di backup di questa macchina (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | La versione fissata di restic che `erpc backup` installa |