--- title: "Inloggen bij ERPC CLI en zien waar uw sleutels worden bewaard" description: "Log deze machine in bij uw ERPC-account, kies waar ERPC CLI de sessie bewaart en zie waar nodesleutels en de door erpc geschreven bestanden staan." canonical: "https://erpc.global/nl/doc/erpc-cli/sign-in-and-keys/" locale: "nl" --- # Inloggen bij ERPC CLI en zien waar uw sleutels worden bewaard Log deze machine in, en ERPC CLI bewaart de sessie in uw sleutelhanger of in 1Password. Deze pagina laat ook zien waar nodesleutels worden bewaard en welke bestanden erpc bijhoudt. Deze pagina beschrijft ERPC CLI `v0.1.0-rc.4`, een pre-release. ## Inloggen ```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` verkrijgt de sessie via de OAuth device authorization grant. Op een machine zonder browser drukt `erpc login --no-browser` de URL en de code af in plaats van een browser te openen, en drukt `erpc signup --no-browser` de inschrijvings-URL af. `erpc whoami` toont van wie de opgeslagen sessie is, en `erpc logout` logt uit en verwijdert de opgeslagen sessie. ## Kiezen waar de sessie wordt bewaard Aan een terminal vraagt `erpc login` welke opslagplaats moet worden gebruikt: de sleutelhanger van het besturingssysteem, de standaardkeuze, of 1Password wanneer dat antwoordt. `--store` en `--vault` kiezen zonder te vragen, en de keuze wordt vastgelegd in `config.toml`, waar de andere commando's ze uitlezen. | `--store` | Waar de sessie wordt bewaard | | --- | --- | | `keychain` | De sleutelhanger van het besturingssysteem | | `1password-desktop` (ook `1password`, `op`) | 1Password, via de desktopapplicatie | | `1password-service-account` | 1Password, via een token van een serviceaccount | | `file` | Een bestand op schijf. Daarmee blijft er een secret op deze machine achter | Is er geen keuze opgegeven of vastgelegd, dan gebruikt erpc een 1Password-serviceaccount wanneer `OP_SERVICE_ACCOUNT_TOKEN` is ingesteld, anders de sleutelhanger van het besturingssysteem als die er is, en anders een bestand in de toestandsmap van erpc. `erpc doctor` meldt welke opslagplaats in gebruik is en waarom. Met een serviceaccount geeft erpc `OP_SERVICE_ACCOUNT_TOKEN` alleen door aan de `op`-processen die het zelf start, en schrijft het dat token nergens weg. Het 1Password-item krijgt de naam van de machine als titel, zodat twee machines nooit één sessie delen. `ERPC_HOST_LABEL` overschrijft die naam. ### Op Linux De sleutelhanger is de Secret Service als er een antwoordt. Anders is het de persistente keyring van de kernel voor uw gebruiker, die in het geheugen staat en nooit op schijf: de sessie blijft geldig tot een herstart of tot ze een paar dagen niet is gebruikt, en daarna wordt opnieuw om `erpc login` gevraagd. Een shell die zonder eigen login is gestart (`su` zonder `-`, `sudo -E`) kan die keyring niet gebruiken; erpc weigert dan en meldt dat. ### Op macOS erpc bereikt de sleutelhanger via `/usr/bin/security`. Elk ander programma dat onder uw gebruiker draait, kan de sessie lezen door ook `security` uit te voeren, terwijl de sleutelhanger de sessie in rust nog steeds versleuteld en buiten bereik van andere gebruikers houdt. ### Wanneer de sessie op schijf staat erpc schrijft de sessie in drie gevallen naar zijn toestandsmap: met de opslagplaats `file`, voor een geparkeerde sessie (een geroteerd refresh-token dat de opslagplaats niet kon bereiken) en na een onderbroken schrijfactie. `erpc doctor` meldt elk dergelijk bestand zolang het bestaat. Op Unix worden deze bestanden aangemaakt met modus `0600`; op Windows stelt erpc zelf geen rechten in. ## Waar nodesleutels worden bewaard De node-inventaris en de back-ups van de originele sleutels die de handleiding van elke chain noemt, worden in 1Password bewaard. Niet elke sleutel staat in 1Password, en een node kan een sleutel bevatten die hij nodig heeft om te draaien. Maak zelf een back-up van wat er op een host staat: wie die host opnieuw opbouwt zonder back-up, raakt het kwijt. Een actieve Sui-validator of een gekozen TRON-witness weigert bovendien te verhuizen naar een nieuwe host. | Node | In 1Password | Op de host | | --- | --- | --- | | Solana-validator (native) | De identity en het sync-keypair die u hebt gemaakt. Het vote account en de withdraw authority krijgt erpc alleen als publieke sleutels | Het sync-keypair, versleuteld voor die host, en vanaf `--activate-validator` ook de identity. De sleutel van het vote account en de opnamesleutels worden nooit geïmporteerd | | Solana-validator (solv) | De gestakete identity, en de withdraw authority tenzij u alleen de publieke sleutel daarvan opgeeft. De sleutel van het vote account wordt verwijderd zodra het account is geverifieerd | Een wegwerp-`unstaked-identity.json` in platte tekst. Een uitrol kopieert nooit de gestakete sleutel of de withdraw authority naar de node | | Solana RPC (native) | De identity die u hebt gemaakt | Dezelfde identity, versleuteld voor die host | | Solana RPC (solv) | De inventaris | De identity, daar gemaakt. Die verlaat de host nooit | | Ethereum-validator | De inventaris | Keystores, hun ontgrendelwachtwoord en de slashinggeschiedenis. De geschiedenis van een back-up stopt bij de snapshot, dus het terugzetten van een sleutel die daarna heeft ondertekend, kan tot slashing leiden: verplaats een signer met `erpc v --chain eth migrate` | | Arc RPC | De consensussleutel | De consensussleutel, versleuteld | | Avalanche | Een back-up van de staking- en BLS-sleutels | Dezelfde sleutels, daar gemaakt bij de eerste uitrol | | Sui-validator | De protocol-, netwerk- en workersleutels, gemaakt op uw eigen machine | Dezelfde drie sleutels, met `systemd-creds` versleuteld voor die host. Nooit de accountsleutel | | Sui full node | De inventaris | De netwerktoegangsgegevens, versleuteld voor die host. Er is geen andere kopie | | TRON-witness | De versleutelde keystore en het wachtwoord ervan | Hetzelfde, als versleutelde systemd-credentials | | Polygon-validator | De signersleutel die `init` genereert. Om de sleutel van de staking owner wordt nooit gevraagd | Dezelfde sleutel, versleuteld voor die host. Zolang de node alleen observeert, draait hij onder een aparte identity | | BNB Chain-validator | Een back-up van het ondertekeningsmateriaal en de peeridentity | De consensussleutel in een versleutelde keystore, de vote-sleutel in een versleutelde wallet, en hun wachtwoorden versleuteld voor die host | | Kaia-validator (consensus- of proxynode) | Een back-up van de node-identity | De node-identity, gemaakt op de host en versleuteld voor die host. De wallets van de operator blijven buiten erpc | | Monad-node (RPC of validator) | Beide originele keystores | Dezelfde keystores, versleuteld voor die host | | Hyperliquid-validator | De hot consensussleutel. Om de sleutel van het cold account wordt nooit gevraagd | De hot key, versleuteld voor die host en alleen geladen door geactiveerde validator-units | | Hyperliquid AQA publisher | De eigen API- of agentsleutel | Dezelfde sleutel, versleuteld voor die host | | NEAR-validator | De consensussleutel | Dezelfde sleutel, versleuteld voor die host | | Arbitrum-validator | De wallet die `init` genereert, en de toegangsgegevens van de provider | De toegangsgegevens van de provider, versleuteld, en vanaf `--activate-signer` ook de wallet, in bezit van root en versleuteld | | Robinhood Chain-validator | De wallet die `init` genereert, en de providerconfiguratie | De providerconfiguratie, versleuteld, en vanaf `--activate-signer` ook de wallet, in bezit van root en versleuteld | | RPC van de OP-familie | De inventaris en de providerwaarden | Toegangsgegevens van de provider, engine-JWT en peeridentities, versleuteld. Maak een back-up van het eigenaarsrecord en het versleutelingssecret van de host | | Nitro RPC | De inventaris en de upstream-toegangsgegevens | De upstream-toegangsgegevens, versleuteld | Andere RPC-nodes bevatten geen ondertekeningssleutel voor een validator, maar hun hosts bewaren wat de client voor zichzelf aanmaakt, zoals een engine-JWT, een peeridentity of een RPC-cookie. Een sleutelback-up alleen maakt het herstel van een validator niet veilig. Volg de herstelprocedure van de chain voordat u een server vervangt of de gegevens ervan terugzet; de handleiding van elke chain beschrijft hoe u de sleutels terugzet ([Nodes](https://erpc.global/nl/doc/erpc-cli/nodes/#chains-en-handleidingen)). Slechts één commando schrijft nodesleutels naar de schijf van uw machine: `erpc validator vote-account` schrijft de identity- en vote-sleutels naar `0600`-bestanden in de toestandsmap terwijl de Solana CLI draait, en wist ze daarna. Een proces dat afbreekt, kan een bestand achterlaten totdat een latere run het opruimt. De tradingsleutel en de secrets van een `erpc worker`-app worden hier los van bewaard: [Sleutels en secrets](https://erpc.global/nl/doc/erpc-cli/worker-secrets/). ## Bestanden die erpc bijhoudt | Pad | Wat het bevat | | --- | --- | | `~/.erpc/config.toml` | Openbare instellingen (`erpc config`) | | `~/.erpc/state/` | De sessie en vergrendelingen (`erpc doctor` meldt hoe de sessie is opgeslagen) | | `~/.erpc/conversations/` | Opgeslagen ERPC AI-gesprekken | | `~/.erpc/memory.json` | Wat ERPC AI onthoudt | | `~/.erpc/vps_hosts.json` | Hostsleutels van VPS'en waarop ERPC AI heeft ingelogd | | `~/.erpc/skills/` | Skills geschreven door `erpc skills install` | | `~/.erpc/storage-key` | De versleutelingssleutel voor de opslag, wanneer `erpc login` de sessie in een bestand bewaart | | `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | Het masterwachtwoord voor back-ups en de `read_write`-sleutel, wanneer `erpc login` de sessie in een bestand bewaart | | `~/.erpc/keystore/` | De worker-keystore: de secrets en de tradingsleutel van een app, elk in een bestand dat met uw wachtzin is versleuteld, op een machine zonder 1Password en zonder blijvende sleutelhanger | | `~/.erpc/workers.toml` | De lijst met `erpc worker`-apps op deze machine | | `~/.erpc/backup.env` | De back-uptoegangsgegevens van deze machine (`0600`) | | `~/.erpc/bin/restic-0.19.1` | De vastgezette restic die `erpc backup` installeert |