---
title: "App की trading key और secrets को सर्वर की डिस्क से दूर रखें"
description: "erpc worker app की trading key और secrets को 1Password, ऑपरेटिंग सिस्टम की कीचेन या एन्क्रिप्टेड keystore में रखता है, और app को मेमोरी में सौंपता है।"
canonical: "https://erpc.global/hi/doc/erpc-cli/worker-secrets/"
locale: "hi"
---

# App की trading key और secrets को सर्वर की डिस्क से दूर रखें

`erpc worker` किसी app की trading key और secrets को 1Password, आपकी कीचेन या एन्क्रिप्टेड keystore में रखता है, और उन्हें app को मेमोरी में सौंपता है, सर्वर की डिस्क पर कभी नहीं।

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

## Trading key app तक कैसे पहुँचती है

Wallet वाले app को उसकी key शुरू होते समय pipe पर मिलती है। सर्वर पर न कोई `wallet.json` होता है, न `.env`, और न कोई copy। erpc key को किसी भी डिस्क पर बिना एन्क्रिप्शन के नहीं लिखता: जिस एकमात्र फ़ाइल में वह उसे रखता है, वह keystore की फ़ाइल है, आपकी मशीन पर, आपके पासफ़्रेज़ के तहत एन्क्रिप्टेड।

- **कहाँ रखी जाती है:** `erpc worker key new` key को 1Password में बनाता है जब `erpc login` session वहाँ रखता है, वरना कीचेन में, वरना keystore में। `erpc.toml` key का reference और उसकी public key दर्ज करता है।
- **सर्वर पर:** erpc worker एजेंट key को सिर्फ़ मेमोरी में रखता है। यह खुद को undumpable बनाता है और अपनी मेमोरी लॉक करता है, और key को file descriptor पर app को सौंपता है; app उसे पढ़ने के बाद मिटा देता है।
- **रीबूट के बाद,** worker लॉक होकर लौटता है: app तब तक नहीं चलता जब तक `erpc worker start` key फिर से न भेजे। जो एजेंट विफल हो जाए या kill किया जाए, उसे systemd फिर से शुरू करता है, और वह भी उसी तरह लॉक होकर लौटता है।
- **Package अपडेट से worker restart नहीं होता।** `deploy`, `needrestart` से worker यूनिट को न छूने के लिए कहता है: अपने automatic mode में यह उन्हें टाल देता है, और टर्मिनल पर पूछे जाने पर उनके लिए इसका default जवाब "नहीं" होता है, इसलिए बिना निगरानी वाला security अपडेट app को restart नहीं करता। जब यह नियम लिखा नहीं जा सका, तो deploy यह बताता है और आगे बढ़ता है, और तब worker इस सुरक्षा के बिना चलता है।

Trading key का नाम `[wallet]` लेता है और कुछ नहीं, और erpc उसे सिर्फ़ टर्मिनल पर मौजूद व्यक्ति के लिए पढ़ता है: किसी AI tool के लिए नहीं, और 1Password service account के साथ नहीं। `[secrets]` की कोई पंक्ति जो `[wallet]` reference का नाम लेती है, या `.wallet` पर खत्म होने वाले किसी `keychain:` या `keystore:` account का, अस्वीकार होती है। Keystore में key के रूप में रखी गई एंट्री secret के रूप में नहीं खुलती। 1Password में, और किसी दूसरे नाम वाले कीचेन account के तहत, कुछ भी key को चिह्नित नहीं करता: `[wallet]` के बिना कोई `erpc.toml` जो `[secrets]` के तहत ऐसे item का नाम लेता है, उसे secret के रूप में पढ़वाता है।

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

1Password वैकल्पिक है। `erpc worker key new` और `erpc worker secret put` उन्हें दी गई चीज़ को इनमें से पहले लागू होने वाले store में रखते हैं, जब तक `--store` कोई store न चुने (`--store 1password --vault <id>`, `--store keychain`, `--store keystore`):

1. **1Password**, जब `erpc login` session वहाँ रखता है या `--vault` दिया गया हो।
2. **ऑपरेटिंग सिस्टम की कीचेन**, जहाँ वह value को रीबूट के बाद भी रखती है: macOS, Windows, और लॉग इन किए हुए session में डेस्कटॉप keyring वाला Linux।
3. **erpc का keystore**, ऐसी Linux मशीन पर जिसमें ऐसा कोई keyring नहीं है: headless सर्वर, WSL, SSH लॉग इन। ऐसी मशीन पर `--store keychain` अस्वीकार होता है।

कीचेन या keystore में, key सिर्फ़ उसी एक मशीन पर होती है, न कोई copy, न कोई sync, और दूसरी मशीन `keychain:` या `keystore:` reference नहीं पढ़ सकती।

मशीन खो जाए या wipe हो जाए, तो wallet भी चला जाता है: उसमें कम रखें, या 1Password इस्तेमाल करें, जिसे vault में लॉग इन की हुई हर मशीन पढ़ सकती है। `erpc login --store 1password-desktop` से 1Password में लॉग इन करें, या जहाँ desktop app नहीं है, वहाँ `op signin` के ज़रिए।

1Password service account किसी app के secrets रख सकता है, पर erpc उसके साथ trading key नहीं पढ़ता। 1Password के साथ, हर read पर app में मंज़ूरी का prompt दिख सकता है, और इंतज़ार के दौरान erpc एक spinner दिखाता है।

## Secret रखें

Secrets, जैसे API tokens और RPC keys, उसी तरह रखे जाते हैं, पर app तक pipe पर नहीं, environment variables के रूप में पहुँचते हैं। `erpc worker secret put <NAME>` value रखता है, और `erpc.toml` में `[secrets]` सिर्फ़ उसका reference रखता है।

```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`** value बनाता है: 32 random bytes, 64 hexadecimal अक्षरों के रूप में।
- **`--from-account`** आपके account की RPC keys में से पहली वह key रखता है जिसे shared RPC स्वीकार करता है। Keys क्रम से आज़माई जाती हैं, primary key सबसे पहले, हर एक पर एक `getHealth`, जवाब के लिए 8 सेकंड। जिस key का जवाब 401 या 403 आए, वह अस्वीकार होती है और अगली आज़माई जाती है, और सिर्फ़ वही key रखी जाती है जिसे RPC ने स्वीकार किया। कमांड बताती है कि यह account की primary key है या कोई दूसरी (`--json` के साथ `account_key`)।
- कोई भी value छापी नहीं जाती, `--json` के साथ भी नहीं। Keystore के पहले इस्तेमाल के लिए, या लॉक keystore के लिए, टर्मिनल पर मौजूद व्यक्ति चाहिए।
- Keys इस मशीन से आज़माई जाती हैं, इसलिए सर्वर के address तक सीमित key यहाँ अस्वीकार होती है, हालाँकि वहाँ वह काम करती है। जब हर key अस्वीकार हो, तो `--from-account` कुछ नहीं रखता, और आप जो key चाहते हैं उसे हाथ से रखते हैं, बिना दिखे टाइप करके या pipe से देकर। जब RPC से पूछा नहीं जा सका, तो यह कुछ नहीं रखता और `erpc.toml` जैसा था वैसा ही रहता है; वही कमांड फिर से चलाएँ।

हाथ से key रखने के लिए:

```bash
erpc worker secret put ERPC_API_KEY        # asks for the value, unseen
```

- `--replace` ऐसे नाम के लिए नई value रखता है जो पहले से सेट है। `erpc worker secret list` secret सेटिंग को नाम से सूचीबद्ध करता है और बताता है कि हर एक कहाँ रखी है।
- डेटा लाइन से मिलने वाली सेटिंग (`GRPC_ENDPOINT`, `SHREDS_ENDPOINT`, `SOLANA_SEND_RPC_ENDPOINT`) कभी secret नहीं होती: `--grpc`, `--shreds` और `--unlimited` उसे सेट करते हैं।

`[secrets]` या `[wallet]` में reference इनमें से एक होता है:

| Reference | Value कहाँ है |
| --- | --- |
| `op://<vault-id>/<item-id>/<field>` | 1Password, vault और item id से |
| `keychain:<service>/<account>` | उस मशीन की ऑपरेटिंग सिस्टम की कीचेन जिसने इसे रखा |
| `keystore:<service>/<account>` | उस मशीन पर erpc का keystore जिसने इसे रखा |

## Keystore

Keystore, directory `~/.erpc/keystore` है (`ERPC_HOME` सेट होने पर उसके तहत `keystore`)। Linux और macOS पर इसकी directories `0700` और फ़ाइलें `0600` होती हैं; Windows पर erpc अपनी ओर से कोई permission सेट नहीं करता।

- `master.json` में एक random 32-byte मास्टर key होती है, जो उस key के तहत सील की जाती है जिसे PBKDF2-HMAC-SHA256 (600,000 iterations) आपके पासफ़्रेज़ से बनाता है। हर एंट्री में एक value होती है, जो उसकी अपनी key के तहत ChaCha20-Poly1305 से सील की जाती है।
- **पासफ़्रेज़:** keystore इस्तेमाल करने वाला पहला `key new` या `secret put` आपसे इसे चुनवाता है, टर्मिनल पर दो बार टाइप करवाकर, 12 या उससे ज़्यादा अक्षर। erpc इसे सिर्फ़ उसी छिपे हुए prompt से लेता है, कभी किसी argument, environment variable या pipe से नहीं।
- **Linux पर अनलॉक:** एक बार पासफ़्रेज़ से keystore खुल जाए, तो अनलॉक kernel के persistent keyring में, मेमोरी में, तब तक रखा जाता है जब तक मशीन फिर से शुरू न हो, keyring अपनी idle expiry तक बिना इस्तेमाल के न पड़ा रहे (तीन दिन, जब तक सिस्टम कुछ और न कहे), या `erpc worker secret lock` न चले। `erpc worker secret unlock` पहले से पासफ़्रेज़ माँग लेता है और बताता है कि अनलॉक कब तक रहेगा। ऐसे shell में जो अपने खुद के लॉग इन के बिना शुरू हुआ हो (`-` के बिना `su`, `sudo -E`), कोई अनलॉक नहीं रखा जाता और हर कमांड पूछती है।
- **टर्मिनल पर कोई न हो तो,** keystore की ज़रूरत वाली कमांड अनलॉक होने पर उसे इस्तेमाल करती है, वरना `erpc worker secret unlock` का नाम लेकर विफल होती है। अनलॉक किया हुआ keystore secrets सौंपता है, trading key नहीं।
- **macOS और Windows पर** (`--store keystore`), कोई अनलॉक नहीं रखा जाता: keystore की ज़रूरत वाली हर कमांड एक बार पासफ़्रेज़ माँगती है, और इसलिए उसे टर्मिनल चाहिए।

### Keystore क्या सुरक्षित रखता है, और क्या नहीं

- **`keystore` directory का बैकअप लें और पासफ़्रेज़ याद रखें।** erpc इनमें से किसी को भी वापस नहीं ला सकता, और इनमें से कोई एक भी खो जाए, तो keystore में जो कुछ है वह चला जाता है।
- जिसके पास keystore की फ़ाइलें और पासफ़्रेज़ हैं, उसके पास key है। PBKDF2 हर अनुमान को धीमा बनाता है, पर अनुमान लगाए जा सकने वाले पासफ़्रेज़ को सुरक्षित नहीं बनाता।
- जब तक keystore अनलॉक है, आपके रूप में चल रहा कोई भी program kernel keyring से मास्टर key पढ़ सकता है (जिस program के session में आपका keyring नहीं है, वह उसे अपने session में जोड़ सकता है) और हर एंट्री खोल सकता है, key की एंट्री भी। erpc के अपने नियम (`[wallet]` जिस key का नाम लेता है, उसे सिर्फ़ टर्मिनल पर मौजूद व्यक्ति के लिए पढ़ना, किसी AI tool के लिए कभी नहीं; keystore में रखी गई key को कभी secret के रूप में न खोलना) वही हैं जो erpc करता है; ये आपके रूप में चल रहे दूसरे programs पर लागू नहीं होते। काम पूरा होने पर `erpc worker secret lock` चलाएँ।
- एंट्री के नाम छिपे नहीं होते, और किसी एंट्री का आकार बताता है कि value कितनी लंबी है।
- बदली हुई फ़ाइल नहीं खुलती; उसी एंट्री की कोई पुरानी copy उसकी जगह वापस रख दी जाए, तो वह खुलती है।
- `erpc worker secret rm` किसी secret की keystore एंट्री को `erpc.toml` में उसकी पंक्ति के साथ हटाता है (जब तक app की कोई दूसरी सेटिंग उसी एंट्री का नाम न लेती हो), और 1Password या कीचेन में रखी value को जहाँ है वहीं छोड़ देता है। यह डिस्क को scrub नहीं करता, और आपके बैकअप में मौजूद copies बनी रहती हैं।
- erpc trading key की एंट्री को कभी न हटाता है, न उसके ऊपर लिखता है। Key बदलने के लिए, पहले funds दूसरी जगह भेजें, फिर उसकी फ़ाइल और `[wallet]` खुद हटाएँ।
- कोई सेटिंग keystore या कीचेन में `WALLET` नाम नहीं ले सकती, चाहे अक्षर छोटे हों या बड़े; `--store 1password` यह नाम स्वीकार करता है।

## Trading key के साथ काम करें

| कमांड | यह क्या करता है |
| --- | --- |
| `erpc worker key new` | Trading key बनाता है और फ़ंड करने के लिए public key छापता है |
| `erpc worker key import <FILE>` | किसी key फ़ाइल को 1Password, कीचेन या keystore में ले जाता है, फिर फ़ाइल को wipe करने की पेशकश करता है |
| `erpc worker key show` | key की public key दिखाता है और यह कि वह कहाँ रखी है |
| `erpc worker key balance` | app की अपनी RPC सेटिंग के ज़रिए key का balance दिखाता है |
| `erpc worker key send --to <ADDRESS> --sol <N>` | टर्मिनल पर आपके "हाँ" के बाद मेमोरी में एक transfer sign करता है। `--all` fee को छोड़कर सब कुछ भेजता है |

जब erpc यह जाने बिना समाप्त हो जाए कि transfer पहुँचा या नहीं, तो फिर से भेजने से पहले उसका signature देखें: दूसरा send एक दूसरा transfer है।