---
title: "Se connecter à ERPC CLI et voir où sont conservées vos clés"
description: "Connectez cette machine à votre compte ERPC, choisissez où ERPC CLI conserve la session et voyez où sont gardés les clés des nœuds et les fichiers d'erpc."
canonical: "https://erpc.global/fr/doc/erpc-cli/sign-in-and-keys/"
locale: "fr"
---

# Se connecter à ERPC CLI et voir où sont conservées vos clés

Connectez cette machine, et ERPC CLI conserve la session dans votre trousseau ou dans 1Password. Cette page indique aussi où se trouvent les clés des nœuds et quels fichiers erpc conserve.

Cette page décrit ERPC CLI `v0.1.0-rc.4`, une préversion.

## Se connecter

```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` obtient la session par le flux OAuth device authorization grant. Sur une machine sans navigateur, `erpc login --no-browser` affiche l'URL et le code au lieu d'ouvrir un navigateur, et `erpc signup --no-browser` affiche l'URL d'inscription. `erpc whoami` indique à qui appartient la session stockée, et `erpc logout` vous déconnecte et supprime la session stockée.

## Choisir où la session est conservée

Dans un terminal, `erpc login` demande quel emplacement de stockage utiliser : le trousseau du système d'exploitation, qui est le choix par défaut, ou 1Password lorsqu'il répond. `--store` et `--vault` font ce choix sans poser de question, et le choix est inscrit dans `config.toml`, où les autres commandes le lisent.

| `--store` | Où la session est conservée |
| --- | --- |
| `keychain` | Le trousseau du système d'exploitation |
| `1password-desktop` (aussi `1password`, `op`) | 1Password, via l'application de bureau |
| `1password-service-account` | 1Password, via un token de compte de service |
| `file` | Un fichier sur le disque. Cela laisse un secret sur cette machine |

Si aucun choix n'est indiqué ni inscrit, erpc utilise un compte de service 1Password lorsque `OP_SERVICE_ACCOUNT_TOKEN` est défini, sinon le trousseau du système d'exploitation s'il en existe un, sinon un fichier dans son répertoire d'état. `erpc doctor` indique quel emplacement de stockage est utilisé et pourquoi. Avec un compte de service, erpc ne transmet `OP_SERVICE_ACCOUNT_TOKEN` qu'aux processus `op` qu'il lance, et n'écrit ce token nulle part.

L'élément 1Password porte le nom de la machine, afin que deux machines ne partagent jamais une même session. `ERPC_HOST_LABEL` remplace ce nom.

### Sous Linux

Le trousseau est le Secret Service là où un service répond. Sinon, c'est le keyring persistant du noyau pour votre utilisateur, qui réside en mémoire et jamais sur le disque : la session dure jusqu'à un redémarrage ou quelques jours sans utilisation, après quoi `erpc login` est de nouveau demandé. Un shell lancé sans connexion propre (`su` sans `-`, `sudo -E`) ne peut pas utiliser ce keyring, et erpc refuse et le signale.

### Sous macOS

erpc accède au trousseau via `/usr/bin/security`. Tout autre programme qui s'exécute sous votre identité peut lire la session en exécutant lui aussi `security`, tandis que le trousseau garde toujours la session chiffrée au repos et hors de portée des autres utilisateurs.

### Quand la session est sur le disque

erpc écrit la session dans son répertoire d'état dans trois cas : avec le stockage `file`, pour une session mise de côté (un refresh token renouvelé par rotation qui n'a pas pu atteindre le stockage), et après une écriture interrompue. `erpc doctor` signale chacun de ces fichiers tant qu'il existe. Sous Unix, ces fichiers sont créés avec le mode `0600` ; sous Windows, erpc ne définit lui-même aucune permission.

## Où sont conservées les clés des nœuds

L'inventaire des nœuds, ainsi que les sauvegardes des clés d'origine que nomme le guide de chaque chaîne, sont conservés dans 1Password. Toutes les clés ne sont pas dans 1Password, et un nœud peut détenir une clé dont il a besoin pour fonctionner. Sauvegardez vous-même ce qui se trouve sur un hôte : reconstruire cet hôte sans sauvegarde fait perdre ce contenu. Par ailleurs, un validateur Sui actif ou un witness TRON élu refuse de passer sur un nouvel hôte.

| Nœud | Dans 1Password | Sur l'hôte |
| --- | --- | --- |
| Validateur Solana (natif) | L'identité et le keypair de synchronisation que vous avez créés. Le compte de vote et l'autorité de retrait sont fournis à erpc uniquement sous forme de clés publiques | Le keypair de synchronisation, chiffré pour cet hôte, et aussi l'identité à partir de `--activate-validator`. Les clés du compte de vote et de retrait ne sont jamais importées |
| Validateur Solana (solv) | L'identité stakée, et l'autorité de retrait sauf si vous ne fournissez que sa clé publique. La clé du compte de vote est supprimée une fois le compte vérifié | Un `unstaked-identity.json` jetable, en texte clair. Un déploiement ne copie jamais la clé stakée ni l'autorité de retrait sur le nœud |
| RPC Solana (natif) | L'identité que vous avez créée | La même identité, chiffrée pour cet hôte |
| RPC Solana (solv) | L'inventaire | L'identité, créée sur place. Elle n'en sort jamais |
| Validateur Ethereum | L'inventaire | Les keystores, leur mot de passe de déverrouillage et l'historique de slashing. L'historique d'une sauvegarde s'arrête à son snapshot, si bien que restaurer une clé qui a signé après celui-ci peut entraîner un slashing : déplacez un signataire avec `erpc v --chain eth migrate` |
| RPC Arc | La clé de consensus | La clé de consensus, chiffrée |
| Avalanche | Une sauvegarde des clés de staking et BLS | Les mêmes clés, créées sur place lors du premier déploiement |
| Validateur Sui | Les clés de protocole, de réseau et de worker, créées sur votre propre machine | Les trois mêmes clés, chiffrées avec `systemd-creds` pour cet hôte. Jamais la clé du compte |
| Nœud complet Sui | L'inventaire | L'identifiant réseau, chiffré pour cet hôte. Il n'en existe aucune autre copie |
| Witness TRON | Le keystore chiffré et son mot de passe | Les mêmes, sous forme d'identifiants systemd chiffrés |
| Validateur Polygon | La clé du signataire que génère `init`. La clé du propriétaire du staking n'est jamais demandée | La même clé, chiffrée pour cet hôte. Tant qu'il ne fait qu'observer, le nœud tourne sous une identité distincte |
| Validateur BNB Chain | Une sauvegarde du matériel de signature et de l'identité de pair | La clé de consensus dans un keystore chiffré, la clé de vote dans un wallet chiffré, et leurs mots de passe chiffrés pour cet hôte |
| Validateur Kaia (nœud de consensus ou nœud proxy) | Une sauvegarde de l'identité du nœud | L'identité du nœud, créée sur l'hôte et chiffrée pour lui. Les wallets de l'opérateur restent en dehors d'erpc |
| Nœud Monad (RPC ou validateur) | Les deux keystores d'origine | Les mêmes keystores, chiffrés pour cet hôte |
| Validateur Hyperliquid | La clé de consensus hot. La clé du compte cold n'est jamais demandée | La clé hot, chiffrée pour cet hôte et chargée uniquement par les unités de validateur activées |
| Publisher AQA Hyperliquid | Sa clé API ou sa clé d'agent dédiée | La même clé, chiffrée pour cet hôte |
| Validateur NEAR | La clé de consensus | La même clé, chiffrée pour cet hôte |
| Validateur Arbitrum | Le wallet que génère `init`, et l'identifiant du fournisseur | L'identifiant du fournisseur, chiffré, et aussi le wallet à partir de `--activate-signer`, appartenant à root et chiffré |
| Validateur Robinhood Chain | Le wallet que génère `init`, et la configuration du fournisseur | La configuration du fournisseur, chiffrée, et aussi le wallet à partir de `--activate-signer`, appartenant à root et chiffré |
| RPC de la famille OP | L'inventaire et les valeurs du fournisseur | L'identifiant du fournisseur, le JWT de l'engine et les identités de pair, chiffrés. Sauvegardez l'enregistrement du propriétaire et le secret de chiffrement de l'hôte |
| RPC Nitro | L'inventaire et l'identifiant amont | L'identifiant amont, chiffré |

Les autres nœuds RPC ne détiennent aucune clé de signature de validateur, mais leurs hôtes conservent ce que le client crée pour lui-même, comme un JWT de l'engine, une identité de pair ou un cookie RPC.

Une sauvegarde de clé ne suffit pas, à elle seule, à rendre sûre la récupération d'un validateur. Suivez la procédure de récupération de la chaîne avant de remplacer un serveur ou de restaurer ses données ; le guide de chaque chaîne indique comment restaurer ses clés ([Nœuds](https://erpc.global/fr/doc/erpc-cli/nodes/#chaînes-et-guides)).

Une seule commande écrit des clés de nœud sur le disque de votre machine : `erpc validator vote-account` écrit les clés d'identité et de vote dans des fichiers `0600` sous le répertoire d'état pendant l'exécution de la Solana CLI, puis les efface. Un processus qui s'interrompt brutalement peut laisser un fichier jusqu'à ce qu'une exécution ultérieure le supprime.

La clé de trading et les secrets d'une application `erpc worker` sont conservés à part : [Clés et secrets](https://erpc.global/fr/doc/erpc-cli/worker-secrets/).

## Fichiers conservés par erpc

| Chemin | Contenu |
| --- | --- |
| `~/.erpc/config.toml` | Paramètres publics (`erpc config`) |
| `~/.erpc/state/` | La session et les verrous (`erpc doctor` indique comment la session est stockée) |
| `~/.erpc/conversations/` | Les conversations ERPC AI enregistrées |
| `~/.erpc/memory.json` | Ce qu'ERPC AI mémorise |
| `~/.erpc/vps_hosts.json` | Les clés d'hôte des VPS auxquels ERPC AI s'est connecté |
| `~/.erpc/skills/` | Les skills écrits par `erpc skills install` |
| `~/.erpc/storage-key` | La clé de chiffrement du stockage, lorsque `erpc login` conserve la session dans un fichier |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | Le mot de passe maître des sauvegardes et la clé `read_write`, lorsque `erpc login` conserve la session dans un fichier |
| `~/.erpc/keystore/` | Le keystore du worker : les secrets et la clé de trading d'une application, chacun dans un fichier chiffré sous votre phrase de passe, sur une machine qui n'a ni 1Password ni trousseau persistant |
| `~/.erpc/workers.toml` | La liste des applications `erpc worker` de cette machine |
| `~/.erpc/backup.env` | Les identifiants de sauvegarde de cette machine (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | Le restic épinglé qu'installe `erpc backup` |