Trading-Schlüssel und Secrets einer Anwendung vom Datenträger des Servers fernhalten

Wie der Trading-Schlüssel zur Anwendung gelangt

• 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.

Festlegen, wo Werte aufbewahrt werden

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.

Ein Secret aufbewahren

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])

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.

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

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.

Der Keystore

• 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