--- title: "Garder la clé de trading et les secrets d'une application hors du disque du serveur" description: "erpc worker conserve la clé de trading et les secrets d'une application dans 1Password, le trousseau de l'OS ou un keystore chiffré, et les transmet en mémoire." canonical: "https://erpc.global/fr/doc/erpc-cli/worker-secrets/" locale: "fr" --- # Garder la clé de trading et les secrets d'une application hors du disque du serveur `erpc worker` conserve la clé de trading et les secrets d'une application dans 1Password, votre trousseau ou un keystore chiffré, et les transmet à l'application en mémoire, jamais sur le disque du serveur. Cette page décrit ERPC CLI `v0.1.0-rc.4`, une préversion. ## Comment la clé de trading parvient à l'application Une application dotée d'un wallet reçoit sa clé par un pipe à son démarrage. Il n'y a ni `wallet.json`, ni `.env`, ni copie sur le serveur. erpc n'écrit la clé en clair sur aucun disque : le seul fichier où il la place est celui du keystore, sur votre machine, chiffré avec votre phrase de passe. - **Où elle est conservée :** `erpc worker key new` crée la clé dans 1Password lorsque `erpc login` y conserve la session, sinon dans le trousseau, sinon dans le keystore. `erpc.toml` contient la référence de la clé et sa clé publique. - **Sur le serveur :** l'agent d'erpc worker ne garde la clé qu'en mémoire. Il se rend non dumpable, verrouille sa mémoire et transmet la clé à l'application sur un descripteur de fichier ; l'application l'efface après l'avoir lue. - **Après un redémarrage,** le worker revient verrouillé : l'application ne s'exécute pas tant que `erpc worker start` n'a pas renvoyé la clé. Un agent qui échoue ou est tué est redémarré par systemd et revient verrouillé de la même façon. - **Une mise à jour de paquet ne redémarre pas un worker.** `deploy` indique à `needrestart` de ne pas toucher aux unités du worker : en mode automatique, il les reporte, et, lorsqu'il est interrogé dans un terminal, sa réponse par défaut pour elles est non ; une mise à jour de sécurité sans surveillance ne redémarre donc pas l'application. Lorsque cette règle n'a pas pu être écrite, le déploiement le signale et continue, et le worker fonctionne alors sans cette protection. La clé de trading est désignée par `[wallet]` et par rien d'autre, et erpc ne la lit que pour une personne devant le terminal : ni pour un outil d'IA, ni avec un compte de service 1Password. Une ligne `[secrets]` qui nomme la référence de `[wallet]`, ou un compte `keychain:` ou `keystore:` se terminant par `.wallet`, est refusée. Dans le keystore, une entrée conservée comme clé ne s'ouvre pas comme secret. Dans 1Password, et sous un compte de trousseau d'un autre nom, rien ne distingue une clé : si un `erpc.toml` sans `[wallet]` nomme un tel élément sous `[secrets]`, celui-ci est lu comme un secret. ## Choisir où conserver les valeurs 1Password est facultatif. `erpc worker key new` et `erpc worker secret put` conservent ce qu'on leur donne dans le premier des emplacements suivants qui s'applique, sauf si `--store` en désigne un (`--store 1password --vault `, `--store keychain`, `--store keystore`) : 1. **1Password**, lorsque `erpc login` y conserve la session ou que `--vault` est indiqué. 2. **Le trousseau de l'OS**, là où il conserve une valeur au-delà d'un redémarrage : macOS, Windows, et Linux avec un keyring de bureau dans une session ouverte. 3. **Le keystore d'erpc**, sur une machine Linux sans un tel keyring : un serveur headless, WSL, une connexion SSH. `--store keychain` est refusé sur une telle machine. Dans le trousseau ou le keystore, la clé n'existe que sur cette seule machine, sans copie ni synchronisation, et une autre machine ne peut pas lire une référence `keychain:` ou `keystore:`. Une machine perdue ou effacée signifie que le wallet est perdu : gardez-y peu de fonds, ou utilisez 1Password, que toute machine connectée au coffre peut lire. Connectez-vous à 1Password avec `erpc login --store 1password-desktop`, ou via `op signin` là où il n'y a pas d'application de bureau. Un compte de service 1Password peut contenir les secrets d'une application, mais erpc ne lit pas de clé de trading avec un tel compte. Avec 1Password, chaque lecture peut afficher une demande d'accord dans l'application, et erpc affiche un indicateur d'attente pendant ce temps. ## Conserver un secret Les secrets, comme les tokens d'API et les clés RPC, sont conservés de la même façon, mais parviennent à l'application sous forme de variables d'environnement, et non par un pipe. `erpc worker secret put ` conserve la valeur, et `[secrets]` dans `erpc.toml` ne contient que sa référence. ```bash erpc worker secret put API_TOKEN --generate # the bot's own API token, made for you and shown to nobody erpc worker secret put ERPC_API_KEY --from-account # the account's RPC key, read from your account (or SOLANA_RPC_ENDPOINT in [vars]) ``` - **`--generate`** crée la valeur : 32 octets aléatoires, sous forme de 64 caractères hexadécimaux. - **`--from-account`** conserve la première des clés RPC de votre compte que le RPC partagé accepte. Les clés sont essayées dans l'ordre, la clé principale en premier, avec un `getHealth` chacune et 8 secondes pour répondre. Une clé qui reçoit la réponse 401 ou 403 est refusée et la suivante est essayée, et seule une clé que le RPC a acceptée est conservée. La commande indique s'il s'agit de la clé principale du compte ou d'une autre (`account_key` avec `--json`). - Aucune des deux valeurs n'est affichée, pas même avec `--json`. La première utilisation du keystore, ou un keystore verrouillé, nécessite une personne devant le terminal. - Les clés sont essayées depuis cette machine : une clé limitée à l'adresse du serveur est donc refusée ici, bien qu'elle fonctionne là-bas. Lorsque toutes les clés sont refusées, `--from-account` ne conserve rien, et vous conservez vous-même la clé voulue, saisie sans affichage ou transmise par un pipe. Lorsque le RPC n'a pas pu être interrogé, rien n'est conservé et `erpc.toml` reste tel quel ; relancez la même commande. Pour conserver une clé à la main : ```bash erpc worker secret put ERPC_API_KEY # asks for the value, unseen ``` - `--replace` conserve une nouvelle valeur pour un nom déjà défini. `erpc worker secret list` liste les paramètres secrets par nom, avec l'endroit où chacun est conservé. - Un paramètre que fournit une ligne de données (`GRPC_ENDPOINT`, `SHREDS_ENDPOINT`, `SOLANA_SEND_RPC_ENDPOINT`) n'est jamais un secret : `--grpc`, `--shreds` et `--unlimited` le définissent. Une référence dans `[secrets]` ou `[wallet]` prend l'une des formes suivantes : | Référence | Où se trouve la valeur | | --- | --- | | `op:////` | 1Password, par identifiant de coffre et d'élément | | `keychain:/` | Le trousseau de l'OS de la machine qui l'a conservée | | `keystore:/` | Le keystore d'erpc sur la machine qui l'a conservée | ## Le keystore Le keystore est le répertoire `~/.erpc/keystore` (`keystore` sous `ERPC_HOME` lorsque celle-ci est définie). Sous Linux et macOS, ses répertoires sont en `0700` et ses fichiers en `0600` ; sous Windows, erpc ne définit aucune permission propre. - `master.json` contient une clé maîtresse aléatoire de 32 octets, scellée sous une clé que PBKDF2-HMAC-SHA256 (600 000 itérations) dérive de votre phrase de passe. Chaque entrée contient une valeur, scellée avec ChaCha20-Poly1305 sous une clé qui lui est propre. - **La phrase de passe :** le premier `key new` ou `secret put` qui utilise le keystore vous la fait choisir, saisie deux fois dans un terminal, de 12 caractères ou plus. erpc ne la prend que depuis cette invite masquée, jamais depuis un argument, une variable d'environnement ou un pipe. - **Déverrouillage sous Linux :** une fois que la phrase de passe a ouvert le keystore, le déverrouillage est conservé dans le keyring persistant du noyau, en mémoire, jusqu'au redémarrage de la machine, jusqu'à ce que le keyring reste inutilisé pendant son délai d'expiration d'inactivité (trois jours, sauf si le système en décide autrement), ou jusqu'à `erpc worker secret lock`. `erpc worker secret unlock` demande la phrase de passe à l'avance et indique jusqu'à quand. Dans un shell lancé sans connexion propre (`su` sans `-`, `sudo -E`), aucun déverrouillage n'est conservé et chaque commande demande la phrase de passe. - **Sans personne devant le terminal,** une commande qui a besoin du keystore utilise le déverrouillage s'il en existe un, et échoue sinon, en indiquant `erpc worker secret unlock`. Un keystore déverrouillé transmet les secrets, pas la clé de trading. - **Sous macOS et Windows** (`--store keystore`), aucun déverrouillage n'est conservé : chaque commande qui a besoin du keystore demande la phrase de passe une fois, et nécessite donc un terminal. ### Ce que le keystore protège, et ce qu'il ne protège pas - **Sauvegardez le répertoire `keystore` et retenez la phrase de passe.** erpc ne peut récupérer ni l'un ni l'autre, et s'il manque l'un ou l'autre, ce que contient le keystore est perdu. - Quiconque possède les fichiers du keystore et la phrase de passe possède la clé. PBKDF2 ralentit chaque tentative, mais ne rend pas sûre une phrase de passe devinable. - Tant que le keystore est déverrouillé, tout programme qui s'exécute sous votre utilisateur peut lire la clé maîtresse dans le keyring du noyau (un programme dont la session ne contient pas votre keyring peut l'y rattacher) et ouvrir chaque entrée, y compris celle d'une clé. Les règles propres à erpc (ne lire la clé désignée par `[wallet]` que pour une personne devant le terminal, jamais pour un outil d'IA ; ne jamais ouvrir comme secret une clé conservée dans le keystore) décrivent ce que fait erpc ; elles ne s'imposent pas aux autres programmes qui s'exécutent sous votre utilisateur. Exécutez `erpc worker secret lock` lorsque vous avez terminé. - Les noms des entrées ne sont pas masqués, et la taille d'une entrée révèle la longueur de la valeur. - Un fichier modifié ne s'ouvre pas ; une copie plus ancienne de la même entrée remise à sa place s'ouvre, elle. - `erpc worker secret rm` supprime l'entrée de keystore d'un secret ainsi que sa ligne dans `erpc.toml` (sauf si un autre paramètre de l'application nomme la même entrée), et laisse en place une valeur stockée dans 1Password ou le trousseau. Il n'écrase pas les données sur le disque, et les copies présentes dans vos sauvegardes subsistent. - erpc ne supprime ni n'écrase jamais l'entrée d'une clé de trading. Pour remplacer une clé, transférez les fonds, puis retirez vous-même son fichier et `[wallet]`. - Un paramètre ne peut pas s'appeler `WALLET`, quelle que soit la casse, dans le keystore ou le trousseau ; `--store 1password` accepte ce nom. ## Utiliser la clé de trading | Commande | Ce qu'elle fait | | --- | --- | | `erpc worker key new` | Crée la clé de trading et affiche la clé publique à approvisionner | | `erpc worker key import ` | Déplace un fichier de clé dans 1Password, le trousseau ou le keystore, puis propose d'effacer le fichier | | `erpc worker key show` | Affiche la clé publique de la clé et l'endroit où elle est conservée | | `erpc worker key balance` | Affiche le solde de la clé, via le paramètre RPC propre à l'application | | `erpc worker key send --to
--sol ` | Signe un transfert en mémoire après votre oui dans un terminal. `--all` envoie tout sauf les frais | Lorsqu'erpc se termine sans savoir si un transfert a abouti, recherchez sa signature avant de renvoyer : un second envoi est un second transfert.