---
title: "ERPC CLI में लॉग इन करें और देखें कि आपकी keys कहाँ रखी जाती हैं"
description: "इस मशीन से अपने ERPC account में लॉग इन करें, चुनें कि ERPC CLI session कहाँ रखे, और देखें कि नोड keys और erpc की लिखी फ़ाइलें कहाँ रहती हैं।"
canonical: "https://erpc.global/hi/doc/erpc-cli/sign-in-and-keys/"
locale: "hi"
---

# ERPC CLI में लॉग इन करें और देखें कि आपकी keys कहाँ रखी जाती हैं

इस मशीन से लॉग इन करें, और ERPC CLI session को आपकी कीचेन या 1Password में रखता है। यह पेज यह भी दिखाता है कि नोड keys कहाँ रखी जाती हैं और erpc कौन-सी फ़ाइलें रखता है।

यह पेज ERPC CLI `v0.1.0-rc.4` के बारे में है, जो एक प्री-रिलीज़ है।

## लॉग इन करें

```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`, OAuth device authorization grant के ज़रिए session लेता है। बिना browser वाली मशीन पर `erpc login --no-browser` browser खोलने के बजाय URL और code छापता है, और `erpc signup --no-browser` sign-up URL छापता है। `erpc whoami` दिखाता है कि सहेजा गया session किसका है, और `erpc logout` लॉग आउट करता है और सहेजा गया session हटा देता है।

## चुनें कि session कहाँ रखा जाए

टर्मिनल में `erpc login` पूछता है कि कौन-सा store इस्तेमाल करना है: ऑपरेटिंग सिस्टम की कीचेन, जो डिफ़ॉल्ट है, या 1Password, अगर वह जवाब देता है। `--store` और `--vault` बिना पूछे चुनाव कर देते हैं, और चुनाव `config.toml` में दर्ज होता है, जहाँ से बाकी कमांड उसे पढ़ती हैं।

| `--store` | session कहाँ रखा जाता है |
| --- | --- |
| `keychain` | ऑपरेटिंग सिस्टम की कीचेन |
| `1password-desktop` (या `1password`, `op`) | 1Password, desktop application के ज़रिए |
| `1password-service-account` | 1Password, service account token के ज़रिए |
| `file` | डिस्क पर एक फ़ाइल। इससे इस मशीन पर एक secret रह जाता है |

जब कोई चुनाव न दिया गया हो और न दर्ज हो, तो `OP_SERVICE_ACCOUNT_TOKEN` सेट होने पर erpc 1Password service account इस्तेमाल करता है, नहीं तो ऑपरेटिंग सिस्टम की कीचेन, अगर वह मौजूद हो, और नहीं तो अपनी state directory में एक फ़ाइल। `erpc doctor` बताता है कि कौन-सा store इस्तेमाल हो रहा है और क्यों। service account के साथ, erpc `OP_SERVICE_ACCOUNT_TOKEN` केवल उन्हीं `op` processes को देता है जिन्हें वह खुद शुरू करता है, और उस token को कहीं नहीं लिखता।

1Password item का शीर्षक मशीन के नाम पर होता है, ताकि दो मशीनें कभी एक session साझा न करें। `ERPC_HOST_LABEL` इस नाम को बदल देता है।

### Linux पर

जहाँ कोई Secret Service जवाब देती है, वहाँ कीचेन वही Secret Service है। नहीं तो यह आपके user के लिए kernel का persistent keyring है, जो मेमोरी में रहता है और डिस्क पर कभी नहीं: session किसी रीबूट तक या कुछ दिन इस्तेमाल न होने तक चलता है, और फिर `erpc login` दोबारा माँगा जाता है। जो shell अपने खुद के login के बिना शुरू हुआ हो (`-` के बिना `su`, `sudo -E`), वह उस keyring का उपयोग नहीं कर सकता, और erpc मना कर देता है और यह बता देता है।

### macOS पर

erpc, `/usr/bin/security` के ज़रिए कीचेन तक पहुँचता है। आपके नाम से चल रहा कोई भी दूसरा program भी `security` चलाकर session पढ़ सकता है, हालाँकि कीचेन फिर भी session को at rest एन्क्रिप्टेड और दूसरे users से दूर रखती है।

### जब session डिस्क पर हो

erpc तीन स्थितियों में session को अपनी state directory में लिखता है: `file` store के साथ, किसी parked session के लिए (एक rotated refresh token जो store तक नहीं पहुँच सका), और किसी अधूरे write के बाद। `erpc doctor` ऐसी हर फ़ाइल की रिपोर्ट तब तक करता है जब तक वह मौजूद है। Unix पर ये फ़ाइलें mode `0600` के साथ बनती हैं; Windows पर erpc अपनी ओर से कोई permissions सेट नहीं करता।

## नोड keys कहाँ रखी जाती हैं

नोड इन्वेंटरी, और हर चेन की गाइड जिन original-key बैकअप का नाम लेती है, वे 1Password में रखे जाते हैं। हर key 1Password में नहीं होती, और कोई नोड चलने के लिए ज़रूरी key अपने पास रख सकता है। होस्ट पर जो है, उसका बैकअप खुद लें: बिना बैकअप के उस होस्ट को दोबारा बनाने पर वह खो जाता है। सक्रिय Sui validator या चुना गया TRON witness भी नए होस्ट पर जाने से मना कर देता है।

| नोड | 1Password में | होस्ट पर |
| --- | --- | --- |
| Solana validator (native) | identity और आपका बनाया sync keypair। vote account और withdraw authority, erpc को केवल public keys के रूप में दिए जाते हैं | sync keypair, उस होस्ट के लिए एन्क्रिप्टेड, और `--activate-validator` से आगे identity भी। vote account और withdrawal keys कभी import नहीं की जातीं |
| Solana validator (solv) | staked identity, और withdraw authority, जब तक आप केवल उसकी public key न दें। account सत्यापित होते ही vote account key हटा दी जाती है | plain text में एक throwaway `unstaked-identity.json`। deploy कभी staked key या withdraw authority को नोड पर copy नहीं करता |
| Solana RPC (native) | आपकी बनाई identity | वही identity, उस होस्ट के लिए एन्क्रिप्टेड |
| Solana RPC (solv) | इन्वेंटरी | identity, जो वहीं बनती है। यह कभी बाहर नहीं जाती |
| Ethereum validator | इन्वेंटरी | keystores, उनका unlock पासवर्ड और slashing history। बैकअप की history उसके snapshot पर रुक जाती है, इसलिए ऐसी key पुनर्स्थापित करने पर, जिसने उसके बाद sign किया हो, slashing हो सकती है: signer को `erpc v --chain eth migrate` से move करें |
| Arc RPC | consensus key | consensus key, एन्क्रिप्टेड |
| Avalanche | staking और BLS keys का बैकअप | वही keys, जो पहले deploy पर वहीं बनती हैं |
| Sui validator | protocol, network और worker keys, जो आपकी अपनी मशीन पर बनती हैं | वही तीनों keys, `systemd-creds` से उस होस्ट के लिए एन्क्रिप्टेड। account key कभी नहीं |
| Sui full node | इन्वेंटरी | network credential, उस होस्ट के लिए एन्क्रिप्टेड। इसकी कोई दूसरी copy नहीं है |
| TRON witness | एन्क्रिप्टेड keystore और उसका पासवर्ड | वही, एन्क्रिप्टेड systemd credentials के रूप में |
| Polygon validator | `init` से generate हुई signer key। staking owner की key कभी नहीं माँगी जाती | वही key, उस होस्ट के लिए एन्क्रिप्टेड। जब तक नोड केवल observe करता है, वह एक अलग identity के तहत चलता है |
| BNB Chain validator | signing material और peer identity का बैकअप | एन्क्रिप्टेड keystore में consensus key, एन्क्रिप्टेड wallet में vote key, और उनके पासवर्ड उस होस्ट के लिए एन्क्रिप्टेड |
| Kaia validator (consensus या proxy नोड) | नोड identity का बैकअप | नोड identity, जो होस्ट पर बनती है और उसी के लिए एन्क्रिप्टेड होती है। ऑपरेटर के wallets, erpc के बाहर रहते हैं |
| Monad नोड (RPC या validator) | दोनों original keystores | वही keystores, उस होस्ट के लिए एन्क्रिप्टेड |
| Hyperliquid validator | hot consensus key। cold account की key कभी नहीं माँगी जाती | hot key, उस होस्ट के लिए एन्क्रिप्टेड, जिसे केवल सक्रिय की गई validator यूनिटें लोड करती हैं |
| Hyperliquid AQA publisher | उसकी dedicated API या एजेंट key | वही key, उस होस्ट के लिए एन्क्रिप्टेड |
| NEAR validator | consensus key | वही key, उस होस्ट के लिए एन्क्रिप्टेड |
| Arbitrum validator | `init` से generate हुआ wallet, और provider credential | provider credential, एन्क्रिप्टेड, और `--activate-signer` से आगे wallet भी, root के स्वामित्व में और एन्क्रिप्टेड |
| Robinhood Chain validator | `init` से generate हुआ wallet, और provider configuration | provider configuration, एन्क्रिप्टेड, और `--activate-signer` से आगे wallet भी, root के स्वामित्व में और एन्क्रिप्टेड |
| OP-family RPC | इन्वेंटरी और provider values | provider credential, engine JWT और peer identities, एन्क्रिप्टेड। owner record और होस्ट के encryption secret का बैकअप लें |
| Nitro RPC | इन्वेंटरी और upstream credential | upstream credential, एन्क्रिप्टेड |

बाकी RPC नोड किसी validator के लिए कोई signing key नहीं रखते, लेकिन उनके होस्ट वह रखते हैं जो client अपने लिए बनाता है, जैसे engine JWT, peer identity या RPC cookie।

केवल key बैकअप होने से validator recovery सुरक्षित नहीं हो जाती। सर्वर बदलने या उसका डेटा पुनर्स्थापित करने से पहले चेन की recovery प्रक्रिया का पालन करें; हर चेन की गाइड बताती है कि उसकी keys कैसे पुनर्स्थापित करें ([नोड](https://erpc.global/hi/doc/erpc-cli/nodes/#चेन-और-गाइड))।

केवल एक कमांड आपकी मशीन की डिस्क पर नोड keys लिखती है: `erpc validator vote-account`, Solana CLI चलने के दौरान identity और vote keys को state directory के तहत mode `0600` वाली फ़ाइलों में लिखती है, और बाद में उन्हें मिटा देती है। अगर process बीच में बंद हो जाए, तो फ़ाइल तब तक रह सकती है जब तक कोई बाद का run उसे साफ़ न कर दे।

`erpc worker` app की trading key और secrets इनसे अलग रखे जाते हैं: [keys और secrets](https://erpc.global/hi/doc/erpc-cli/worker-secrets/)।

## erpc कौन-सी फ़ाइलें रखता है

| Path | इसमें क्या होता है |
| --- | --- |
| `~/.erpc/config.toml` | सार्वजनिक सेटिंग्स (`erpc config`) |
| `~/.erpc/state/` | session और लॉक (`erpc doctor` बताता है कि session कैसे रखा गया है) |
| `~/.erpc/conversations/` | सहेजी गई ERPC AI बातचीत |
| `~/.erpc/memory.json` | ERPC AI को क्या याद है |
| `~/.erpc/vps_hosts.json` | उन VPS की host keys जिनमें ERPC AI ने लॉग इन किया |
| `~/.erpc/skills/` | `erpc skills install` से लिखी गई स्किल्स |
| `~/.erpc/storage-key` | स्टोरेज encryption key, जब `erpc login` session को फ़ाइल में रखता है |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | बैकअप का मास्टर पासवर्ड और `read_write` key, जब `erpc login` session को फ़ाइल में रखता है |
| `~/.erpc/keystore/` | worker keystore: app के secrets और trading key, हर एक आपके पासफ़्रेज़ से एन्क्रिप्ट की गई फ़ाइल में, ऐसी मशीन पर जिस पर न 1Password हो और न टिकने वाली कीचेन |
| `~/.erpc/workers.toml` | इस मशीन पर `erpc worker` apps की सूची |
| `~/.erpc/backup.env` | इस मशीन के बैकअप credentials (`0600`) |
| `~/.erpc/bin/restic-0.19.1` | पिन किया गया restic जिसे `erpc backup` इंस्टॉल करता है |