---
title: "Bei ERPC CLI anmelden und sehen, wo Ihre Schlüssel aufbewahrt werden"
description: "Melden Sie diesen Rechner bei Ihrem ERPC-Konto an, wählen Sie den Ort der Sitzung und sehen Sie, wo Knotenschlüssel und die Dateien von erpc liegen."
canonical: "https://erpc.global/de/doc/erpc-cli/sign-in-and-keys/"
locale: "de"
---

# Bei ERPC CLI anmelden und sehen, wo Ihre Schlüssel aufbewahrt werden

Melden Sie diesen Rechner an, und ERPC CLI bewahrt die Sitzung in Ihrem Schlüsselbund oder in 1Password auf. Diese Seite zeigt außerdem, wo Knotenschlüssel liegen und welche Dateien erpc aufbewahrt.

Diese Seite beschreibt ERPC CLI `v0.1.0-rc.4`, eine Vorabversion.

## Anmelden

```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` erhält die Sitzung über den OAuth Device Authorization Grant. Auf einem Rechner ohne Browser gibt `erpc login --no-browser` die URL und den Code aus, statt einen Browser zu öffnen, und `erpc signup --no-browser` gibt die Registrierungs-URL aus. `erpc whoami` zeigt, wem die gespeicherte Sitzung gehört, und `erpc logout` meldet ab und entfernt die gespeicherte Sitzung.

## Wählen, wo die Sitzung aufbewahrt wird

An einem Terminal fragt `erpc login`, welcher Speicherort verwendet werden soll: der Schlüsselbund des Betriebssystems, der Standard, oder 1Password, wenn es antwortet. `--store` und `--vault` treffen die Wahl ohne Nachfrage, und die Wahl wird in `config.toml` festgehalten, wo die anderen Befehle sie lesen.

| `--store` | Wo die Sitzung aufbewahrt wird |
| --- | --- |
| `keychain` | Der Schlüsselbund des Betriebssystems |
| `1password-desktop` (auch `1password`, `op`) | 1Password, über die Desktop-Anwendung |
| `1password-service-account` | 1Password, über ein Service-Account-Token |
| `file` | Eine Datei auf dem Datenträger. Damit bleibt ein Secret auf diesem Rechner |

Wurde keine Wahl angegeben oder festgehalten, verwendet erpc einen 1Password-Service-Account, wenn `OP_SERVICE_ACCOUNT_TOKEN` gesetzt ist, andernfalls den Schlüsselbund des Betriebssystems, sofern es einen gibt, andernfalls eine Datei in seinem Zustandsverzeichnis. `erpc doctor` meldet, welcher Speicherort verwendet wird und warum. Mit einem Service-Account übergibt erpc `OP_SERVICE_ACCOUNT_TOKEN` nur an die Prozesse von `op`, die es selbst startet, und schreibt dieses Token nirgendwohin.

Das 1Password-Element trägt den Namen des Rechners als Titel, damit sich zwei Rechner nie eine Sitzung teilen. `ERPC_HOST_LABEL` überschreibt den Namen.

### Unter Linux

Der Schlüsselbund ist der Secret Service, sofern einer antwortet. Andernfalls ist es der persistente Kernel-Keyring Ihres Benutzers, der im Arbeitsspeicher liegt und nie auf dem Datenträger: Die Sitzung bleibt bis zu einem Neustart bestehen oder bis sie einige Tage nicht genutzt wurde, danach wird erneut `erpc login` verlangt. Eine Shell, die ohne eigenen Login gestartet wurde (`su` ohne `-`, `sudo -E`), kann diesen Keyring nicht verwenden; erpc lehnt dann ab und weist darauf hin.

### Unter macOS

erpc greift über `/usr/bin/security` auf den Schlüsselbund zu. Jedes andere Programm, das unter Ihrem Benutzer läuft, kann die Sitzung lesen, indem es ebenfalls `security` ausführt; der Schlüsselbund hält die Sitzung dennoch im Ruhezustand verschlüsselt und von anderen Benutzern fern.

### Wenn die Sitzung auf dem Datenträger liegt

erpc schreibt die Sitzung in drei Fällen in sein Zustandsverzeichnis: mit dem Speicherort `file`, für eine geparkte Sitzung (ein rotiertes Refresh-Token, das den Speicherort nicht erreichen konnte) und nach einem unterbrochenen Schreibvorgang. `erpc doctor` meldet jede solche Datei, solange sie existiert. Unter Unix werden diese Dateien mit dem Modus `0600` angelegt; unter Windows setzt erpc keine eigenen Berechtigungen.

## Wo Knotenschlüssel aufbewahrt werden

Das Knoteninventar und die Backups der Originalschlüssel, die der Leitfaden jeder Chain nennt, werden in 1Password aufbewahrt. Nicht jeder Schlüssel liegt in 1Password, und ein Knoten kann einen Schlüssel halten, den er für den Betrieb braucht. Sichern Sie selbst, was auf einem Host liegt: Wer diesen Host ohne Backup neu aufbaut, verliert es. Ein aktiver Sui-Validator oder ein gewählter TRON-Witness lehnt außerdem einen Umzug auf einen neuen Host ab.

| Knoten | In 1Password | Auf dem Host |
| --- | --- | --- |
| Solana-Validator (native) | Die Identität und das Sync-Keypair, die Sie erstellt haben. Der Vote-Account und die Withdraw-Authority werden erpc nur als öffentliche Schlüssel übergeben | Das Sync-Keypair, für diesen Host verschlüsselt, und ab `--activate-validator` auch die Identität. Die Vote-Account- und Withdraw-Schlüssel werden nie importiert |
| Solana-Validator (solv) | Die gestakte Identität und die Withdraw-Authority, sofern Sie nicht nur ihren öffentlichen Schlüssel angeben. Der Schlüssel des Vote-Accounts wird gelöscht, sobald der Account verifiziert ist | Eine Wegwerfdatei `unstaked-identity.json` im Klartext. Eine Bereitstellung kopiert nie den gestakten Schlüssel oder die Withdraw-Authority auf den Knoten |
| Solana RPC (native) | Die Identität, die Sie erstellt haben | Dieselbe Identität, für diesen Host verschlüsselt |
| Solana RPC (solv) | Das Inventar | Die Identität, dort erstellt. Sie verlässt den Host nie |
| Ethereum-Validator | Das Inventar | Keystores, ihr Entsperrpasswort und die Slashing-Historie. Die Historie eines Backups endet bei seinem Snapshot, daher kann das Wiederherstellen eines Schlüssels, der danach signiert hat, zu Slashing führen: Ziehen Sie einen Signer mit `erpc v --chain eth migrate` um |
| Arc RPC | Der Konsensschlüssel | Der Konsensschlüssel, verschlüsselt |
| Avalanche | Ein Backup der Staking- und BLS-Schlüssel | Dieselben Schlüssel, dort bei der ersten Bereitstellung erstellt |
| Sui-Validator | Die Protokoll-, Netzwerk- und Worker-Schlüssel, auf Ihrem eigenen Rechner erstellt | Dieselben drei Schlüssel, mit `systemd-creds` für diesen Host verschlüsselt. Nie der Kontoschlüssel |
| Sui-Full-Node | Das Inventar | Die Netzwerk-Zugangsdaten, für diesen Host verschlüsselt. Es gibt keine andere Kopie |
| TRON-Witness | Der verschlüsselte Keystore und sein Passwort | Dasselbe, als verschlüsselte systemd-Credentials |
| Polygon-Validator | Der Signer-Schlüssel, den `init` erzeugt. Nach dem Schlüssel des Staking-Owners wird nie gefragt | Derselbe Schlüssel, für diesen Host verschlüsselt. Solange der Knoten nur beobachtet, läuft er unter einer separaten Identität |
| BNB-Chain-Validator | Ein Backup des Signaturmaterials und der Peer-Identität | Der Konsensschlüssel in einem verschlüsselten Keystore, der Vote-Schlüssel in einer verschlüsselten Wallet und ihre Passwörter, für diesen Host verschlüsselt |
| Kaia-Validator (Konsens- oder Proxy-Knoten) | Ein Backup der Knotenidentität | Die Knotenidentität, auf dem Host erstellt und für ihn verschlüsselt. Die Wallets des Betreibers bleiben außerhalb von erpc |
| Monad-Knoten (RPC oder Validator) | Beide ursprünglichen Keystores | Dieselben Keystores, für diesen Host verschlüsselt |
| Hyperliquid-Validator | Der Hot-Konsensschlüssel. Nach dem Schlüssel des Cold-Kontos wird nie gefragt | Der Hot-Key, für diesen Host verschlüsselt und nur von aktivierten Validator-Units geladen |
| Hyperliquid-AQA-Publisher | Sein eigener API- oder Agent-Schlüssel | Derselbe Schlüssel, für diesen Host verschlüsselt |
| NEAR-Validator | Der Konsensschlüssel | Derselbe Schlüssel, für diesen Host verschlüsselt |
| Arbitrum-Validator | Die Wallet, die `init` erzeugt, und die Provider-Zugangsdaten | Die Provider-Zugangsdaten, verschlüsselt, und ab `--activate-signer` auch die Wallet, im Besitz von root und verschlüsselt |
| Robinhood-Chain-Validator | Die Wallet, die `init` erzeugt, und die Provider-Konfiguration | Die Provider-Konfiguration, verschlüsselt, und ab `--activate-signer` auch die Wallet, im Besitz von root und verschlüsselt |
| RPC der OP-Familie | Das Inventar und die Provider-Werte | Provider-Zugangsdaten, Engine-JWT und Peer-Identitäten, verschlüsselt. Sichern Sie den Eigentümereintrag und das Verschlüsselungs-Secret des Hosts |
| Nitro RPC | Das Inventar und die Upstream-Zugangsdaten | Die Upstream-Zugangsdaten, verschlüsselt |

Andere RPC-Knoten halten keinen Signaturschlüssel für einen Validator, aber ihre Hosts bewahren auf, was der Client für sich selbst erzeugt, etwa ein Engine-JWT, eine Peer-Identität oder ein RPC-Cookie.

Ein Schlüssel-Backup allein macht die Wiederherstellung eines Validators nicht sicher. Befolgen Sie das Wiederherstellungsverfahren der Chain, bevor Sie einen Server ersetzen oder seine Daten wiederherstellen; der Leitfaden jeder Chain beschreibt, wie ihre Schlüssel wiederhergestellt werden ([Knoten](https://erpc.global/de/doc/erpc-cli/nodes/#chains-und-leitfäden)).

Ein einziger Befehl schreibt Knotenschlüssel auf Ihrem Rechner auf den Datenträger: `erpc validator vote-account` schreibt die Identitäts- und Vote-Schlüssel in Dateien mit `0600` unter dem Zustandsverzeichnis, während die Solana CLI läuft, und vernichtet sie danach. Ein Prozess, der abstürzt, kann eine Datei hinterlassen, bis ein späterer Lauf sie beseitigt.

Der Trading-Schlüssel und die Secrets einer Anwendung von `erpc worker` werden getrennt davon aufbewahrt: [Schlüssel und Secrets](https://erpc.global/de/doc/erpc-cli/worker-secrets/).

## Dateien, die erpc aufbewahrt

| Pfad | Was er enthält |
| --- | --- |
| `~/.erpc/config.toml` | Öffentliche Einstellungen (`erpc config`) |
| `~/.erpc/state/` | Die Sitzung und Sperren (`erpc doctor` sagt, wie die Sitzung gespeichert ist) |
| `~/.erpc/conversations/` | Gespeicherte Konversationen mit ERPC AI |
| `~/.erpc/memory.json` | Was sich ERPC AI merkt |
| `~/.erpc/vps_hosts.json` | Host-Schlüssel der VPSs, bei denen sich ERPC AI angemeldet hat |
| `~/.erpc/skills/` | Von `erpc skills install` geschriebene Skills |
| `~/.erpc/storage-key` | Der Verschlüsselungsschlüssel für den Speicher, wenn `erpc login` die Sitzung in einer Datei aufbewahrt |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | Das Master-Passwort für Backups und der Schlüssel `read_write`, wenn `erpc login` die Sitzung in einer Datei aufbewahrt |
| `~/.erpc/keystore/` | Der Worker-Keystore: die Secrets und der Trading-Schlüssel einer Anwendung, jeweils in einer mit Ihrer Passphrase verschlüsselten Datei, auf einem Rechner ohne 1Password und ohne dauerhaften Schlüsselbund |
| `~/.erpc/workers.toml` | Die Liste der Anwendungen von `erpc worker` auf diesem Rechner |
| `~/.erpc/backup.env` | Die Backup-Zugangsdaten dieses Rechners (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | Das fixierte restic, das `erpc backup` installiert |