--- title: "Trading-Schlüssel und Secrets einer Anwendung vom Datenträger des Servers fernhalten" description: "erpc worker verwahrt Trading-Schlüssel und Secrets in 1Password, im OS-Schlüsselbund oder einem verschlüsselten Keystore und übergibt sie im Arbeitsspeicher." canonical: "https://erpc.global/de/doc/erpc-cli/worker-secrets/" locale: "de" --- # Trading-Schlüssel und Secrets einer Anwendung vom Datenträger des Servers fernhalten `erpc worker` bewahrt den Trading-Schlüssel und die Secrets einer Anwendung in 1Password, in Ihrem Schlüsselbund oder in einem verschlüsselten Keystore auf und übergibt sie der Anwendung im Arbeitsspeicher, nie über den Datenträger des Servers. Diese Seite beschreibt ERPC CLI `v0.1.0-rc.4`, eine Vorabversion. ## Wie der Trading-Schlüssel zur Anwendung gelangt Eine Anwendung mit Wallet erhält ihren Schlüssel beim Start über eine Pipe. Auf dem Server gibt es keine `wallet.json`, keine `.env` und keine Kopie. erpc schreibt den Schlüssel unverschlüsselt auf keinen Datenträger: Die einzige Datei, in die es ihn schreibt, ist die des Keystores, auf Ihrem Rechner, verschlüsselt mit Ihrer Passphrase. - **Wo er aufbewahrt wird:** `erpc worker key new` erstellt den Schlüssel in 1Password, wenn `erpc login` die Sitzung dort aufbewahrt, sonst im Schlüsselbund, sonst im Keystore. `erpc.toml` hält die Referenz des Schlüssels und seinen öffentlichen Schlüssel fest. - **Auf dem Server:** Der Agent von erpc worker hält den Schlüssel nur im Arbeitsspeicher. Er macht sich selbst nicht dumpbar, sperrt seinen Arbeitsspeicher und übergibt den Schlüssel der Anwendung über einen Dateideskriptor; die Anwendung vernichtet ihn nach dem Lesen. - **Nach einem Neustart** kommt der Worker gesperrt zurück: Die Anwendung läuft erst, wenn `erpc worker start` den Schlüssel erneut sendet. Ein Agent, der ausfällt oder beendet wird, wird von systemd neu gestartet und kommt auf dieselbe Weise gesperrt zurück. - **Ein Paket-Update startet einen Worker nicht neu.** `deploy` weist `needrestart` an, die Worker-Units in Ruhe zu lassen: Im automatischen Modus stellt es sie zurück, und wird es an einem Terminal gefragt, lautet seine Standardantwort für sie Nein, sodass ein unbeaufsichtigtes Sicherheitsupdate die Anwendung nicht neu startet. Konnte diese Regel nicht geschrieben werden, meldet die Bereitstellung das und fährt fort, und der Worker läuft dann ohne diesen Schutz. Der Trading-Schlüssel wird durch `[wallet]` benannt und durch nichts anderes, und erpc liest ihn nur für eine Person am Terminal: nicht für ein KI-Werkzeug und nicht mit einem 1Password-Dienstkonto. Eine `[secrets]`-Zeile, die die Referenz aus `[wallet]` nennt, oder ein `keychain:`- oder `keystore:`-Konto, das auf `.wallet` endet, wird abgelehnt. Im Keystore öffnet sich ein als Schlüssel aufbewahrter Eintrag nicht als Secret. In 1Password und unter einem Schlüsselbund-Konto mit anderem Namen kennzeichnet nichts einen Schlüssel: Nennt eine `erpc.toml` ohne `[wallet]` ein solches Element unter `[secrets]`, wird es als Secret gelesen. ## Festlegen, wo Werte aufbewahrt werden 1Password ist optional. `erpc worker key new` und `erpc worker secret put` bewahren, was sie erhalten, an der ersten der folgenden Stellen auf, die zutrifft, sofern `--store` keine nennt (`--store 1password --vault `, `--store keychain`, `--store keystore`): 1. **1Password**, wenn `erpc login` die Sitzung dort aufbewahrt oder `--vault` angegeben ist. 2. **Der OS-Schlüsselbund**, dort, wo er einen Wert über einen Neustart hinaus behält: macOS, Windows und Linux mit einem Desktop-Keyring in einer angemeldeten Sitzung. 3. **Der Keystore von erpc**, auf einem Linux-Rechner ohne einen solchen Keyring: ein Headless-Server, WSL, eine SSH-Anmeldung. `--store keychain` wird auf einem solchen Rechner abgelehnt. Im Schlüsselbund oder im Keystore existiert der Schlüssel nur auf diesem einen Rechner, ohne Kopie und ohne Synchronisierung, und ein anderer Rechner kann eine `keychain:`- oder `keystore:`-Referenz nicht lesen. Geht der Rechner verloren oder wird er gelöscht, ist die Wallet weg: Bewahren Sie wenig darin auf, oder verwenden Sie 1Password, das jeder beim Tresor angemeldete Rechner lesen kann. Melden Sie sich mit `erpc login --store 1password-desktop` bei 1Password an, oder über `op signin`, wo es keine Desktop-App gibt. Ein 1Password-Dienstkonto kann die Secrets einer Anwendung enthalten, aber erpc liest einen Trading-Schlüssel nicht mit einem solchen Konto. Mit 1Password kann jeder Lesevorgang in der App eine Bestätigungsabfrage anzeigen, und erpc zeigt einen Spinner, während es wartet. ## Ein Secret aufbewahren Secrets wie API-Tokens und RPC-Schlüssel werden auf dieselbe Weise aufbewahrt, gelangen aber als Umgebungsvariablen zur Anwendung, nicht über eine Pipe. `erpc worker secret put ` bewahrt den Wert auf, und `[secrets]` in `erpc.toml` enthält nur seine Referenz. ```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`** erzeugt den Wert: 32 Zufallsbytes als 64 hexadezimale Zeichen. - **`--from-account`** bewahrt den ersten RPC-Schlüssel Ihres Kontos auf, den der Shared RPC annimmt. Die Schlüssel werden der Reihe nach versucht, der primäre zuerst, mit je einem `getHealth`, das 8 Sekunden Zeit für die Antwort hat. Ein Schlüssel, auf den mit 401 oder 403 geantwortet wird, wird abgelehnt und der nächste versucht, und nur ein Schlüssel, den der RPC angenommen hat, wird aufbewahrt. Der Befehl meldet, ob es der primäre Schlüssel des Kontos ist oder ein anderer (`account_key` mit `--json`). - Keiner der beiden Werte wird ausgegeben, auch nicht mit `--json`. Die erste Verwendung des Keystores oder ein gesperrter Keystore braucht eine Person am Terminal. - Die Schlüssel werden von diesem Rechner aus versucht, daher wird ein Schlüssel, der auf die Adresse des Servers beschränkt ist, hier abgelehnt, obwohl er dort funktioniert. Werden alle Schlüssel abgelehnt, bewahrt `--from-account` nichts auf, und Sie bewahren den gemeinten Schlüssel von Hand auf, verdeckt eingegeben oder per Pipe übergeben. Konnte der RPC nicht gefragt werden, bewahrt der Befehl nichts auf, und `erpc.toml` bleibt unverändert; führen Sie denselben Befehl erneut aus. Um einen Schlüssel von Hand aufzubewahren: ```bash erpc worker secret put ERPC_API_KEY # asks for the value, unseen ``` - `--replace` bewahrt einen neuen Wert für einen Namen auf, der bereits gesetzt ist. `erpc worker secret list` listet die geheimen Einstellungen nach Namen auf und zeigt, wo jede aufbewahrt wird. - Eine Einstellung, die eine Datenleitung bereitstellt (`GRPC_ENDPOINT`, `SHREDS_ENDPOINT`, `SOLANA_SEND_RPC_ENDPOINT`), ist nie ein Secret: `--grpc`, `--shreds` und `--unlimited` setzen sie. Eine Referenz in `[secrets]` oder `[wallet]` hat eine dieser Formen: | Referenz | Wo der Wert liegt | | --- | --- | | `op:////` | 1Password, nach Tresor- und Element-ID | | `keychain:/` | Der OS-Schlüsselbund des Rechners, auf dem er aufbewahrt wurde | | `keystore:/` | Der Keystore von erpc auf dem Rechner, auf dem er aufbewahrt wurde | ## Der Keystore Der Keystore ist das Verzeichnis `~/.erpc/keystore` (`keystore` unter `ERPC_HOME`, wenn dieses gesetzt ist). Unter Linux und macOS haben seine Verzeichnisse `0700` und seine Dateien `0600`; unter Windows setzt erpc keine eigenen Berechtigungen. - `master.json` enthält einen zufälligen 32-Byte-Hauptschlüssel, versiegelt mit einem Schlüssel, den PBKDF2-HMAC-SHA256 (600.000 Iterationen) aus Ihrer Passphrase ableitet. Jeder Eintrag enthält einen Wert, versiegelt mit ChaCha20-Poly1305 unter einem eigenen Schlüssel. - **Die Passphrase:** Der erste Aufruf von `key new` oder `secret put`, der den Keystore verwendet, lässt Sie sie wählen, zweimal an einem Terminal eingegeben, mindestens 12 Zeichen. erpc nimmt sie nur aus dieser verdeckten Abfrage entgegen, nie aus einem Argument, einer Umgebungsvariable oder einer Pipe. - **Entsperren unter Linux:** Sobald die Passphrase den Keystore geöffnet hat, wird die Entsperrung im persistenten Kernel-Keyring gehalten, im Arbeitsspeicher, bis der Rechner neu startet, der Keyring bis zu seinem Leerlaufablauf ungenutzt bleibt (drei Tage, sofern das System nichts anderes festlegt) oder `erpc worker secret lock` ausgeführt wird. `erpc worker secret unlock` fragt die Passphrase im Voraus ab und meldet, bis wann die Entsperrung gilt. In einer Shell, die ohne eigenen Login gestartet wurde (`su` ohne `-`, `sudo -E`), wird keine Entsperrung gehalten, und jeder Befehl fragt. - **Ohne Person am Terminal** verwendet ein Befehl, der den Keystore braucht, die Entsperrung, wenn es eine gibt, und schlägt andernfalls fehl, wobei er `erpc worker secret unlock` nennt. Ein entsperrter Keystore gibt Secrets heraus, nicht den Trading-Schlüssel. - **Unter macOS und Windows** (`--store keystore`) wird keine Entsperrung gehalten: Jeder Befehl, der den Keystore braucht, fragt einmal nach der Passphrase und braucht daher ein Terminal. ### Was der Keystore schützt und was nicht - **Sichern Sie das Verzeichnis `keystore` und merken Sie sich die Passphrase.** erpc kann keines von beiden wiederherstellen, und fehlt eines davon, ist verloren, was der Keystore enthält. - Wer die Keystore-Dateien und die Passphrase hat, hat den Schlüssel. PBKDF2 macht jeden Rateversuch langsam, macht eine erratbare Passphrase aber nicht sicher. - Solange der Keystore entsperrt ist, kann jedes Programm, das unter Ihrem Benutzer läuft, den Hauptschlüssel aus dem Kernel-Keyring lesen (ein Programm, dessen Sitzung Ihren Keyring nicht enthält, kann ihn einbinden) und jeden Eintrag öffnen, auch den eines Schlüssels. Die eigenen Regeln von erpc (den Schlüssel, den `[wallet]` nennt, nur für eine Person am Terminal zu lesen, nie für ein KI-Werkzeug; einen im Keystore aufbewahrten Schlüssel nie als Secret zu öffnen) sind das, was erpc tut; sie binden keine anderen Programme, die unter Ihrem Benutzer laufen. Führen Sie `erpc worker secret lock` aus, wenn Sie fertig sind. - Die Namen der Einträge sind nicht verborgen, und die Größe eines Eintrags zeigt, wie lang der Wert ist. - Eine veränderte Datei öffnet sich nicht; eine ältere Kopie desselben Eintrags, die an ihre Stelle zurückgelegt wird, schon. - `erpc worker secret rm` löscht den Keystore-Eintrag eines Secrets zusammen mit seiner Zeile in `erpc.toml` (außer wenn eine andere Einstellung der Anwendung denselben Eintrag nennt) und lässt einen Wert in 1Password oder im Schlüsselbund, wo er ist. Es bereinigt den Datenträger nicht, und Kopien in Ihren Backups bleiben bestehen. - erpc löscht oder überschreibt nie den Eintrag eines Trading-Schlüssels. Um einen Schlüssel zu ersetzen, verschieben Sie die Mittel und entfernen dann seine Datei und `[wallet]` selbst. - Eine Einstellung kann nicht `WALLET` heißen, unabhängig von der Groß- und Kleinschreibung, weder im Keystore noch im Schlüsselbund; `--store 1password` akzeptiert den Namen. ## Mit dem Trading-Schlüssel arbeiten | Befehl | Was er tut | | --- | --- | | `erpc worker key new` | Erstellt den Trading-Schlüssel und gibt den öffentlichen Schlüssel zum Aufladen aus | | `erpc worker key import ` | Verschiebt eine Schlüsseldatei in 1Password, den Schlüsselbund oder den Keystore und bietet dann an, die Datei zu vernichten | | `erpc worker key show` | Zeigt den öffentlichen Schlüssel des Schlüssels und wo er aufbewahrt wird | | `erpc worker key balance` | Zeigt das Guthaben des Schlüssels, über die eigene RPC-Einstellung der Anwendung | | `erpc worker key send --to
--sol ` | Signiert eine Überweisung im Arbeitsspeicher nach Ihrem Ja an einem Terminal. `--all` sendet alles außer der Gebühr | Endet erpc, ohne zu wissen, ob eine Überweisung angekommen ist, sehen Sie ihre Signatur nach, bevor Sie erneut senden: Ein zweites Senden ist eine zweite Überweisung.