Add static keychain publication workflow
This commit is contained in:
parent
b6ffcde54c
commit
cfd41522d1
11 changed files with 1852 additions and 46 deletions
41
README.md
41
README.md
|
|
@ -448,6 +448,29 @@ geth keychain admin-add \
|
|||
--signing-key ~/.ssh/id_ed25519_sk \
|
||||
--principal admin
|
||||
geth keychain allowed-signers > /tmp/geth.allowed_signers
|
||||
geth keychain allowed-signers --out /tmp/geth.allowed_signers
|
||||
geth keychain sign-file \
|
||||
--in /tmp/authorized_keys \
|
||||
--out /tmp/authorized_keys.sig \
|
||||
--signing-key ~/.ssh/id_ed25519_sk
|
||||
geth keychain verify-file \
|
||||
--in /tmp/authorized_keys \
|
||||
--signature /tmp/authorized_keys.sig
|
||||
geth keychain sigchain --out /tmp/geth.sigchain.jsonl
|
||||
geth keychain publish-bundle \
|
||||
--out ./public/.well-known/sshsigchain \
|
||||
--signing-key ~/.ssh/id_ed25519_sk \
|
||||
--snapshot authorized_keys=/tmp/authorized_keys
|
||||
geth keychain verify-checkpoint \
|
||||
--checkpoint /tmp/geth.sigchain.checkpoint.json \
|
||||
--signature /tmp/geth.sigchain.checkpoint.json.sig \
|
||||
--sigchain /tmp/geth.sigchain.jsonl \
|
||||
--allowed-signers /tmp/geth.allowed_signers
|
||||
geth keychain fetch --url https://example.com/.well-known/sshsigchain/ --import
|
||||
geth keychain verify-sigchain --in /tmp/geth.sigchain.jsonl
|
||||
geth keychain import-sigchain --in /tmp/geth.sigchain.jsonl
|
||||
geth keychain explain <op-id>
|
||||
geth keychain explain-signer <key-id>
|
||||
geth keychain verify
|
||||
```
|
||||
|
||||
|
|
@ -459,7 +482,23 @@ trusted state. The reusable mechanics live in the `geth-keychain` crate,
|
|||
including application-specific signature profiles, allowed-signers projection,
|
||||
replay verification through a caller-provided verifier trait, and an appendable
|
||||
JSONL sigchain file format suitable for static hosting with HTTP caching/range
|
||||
requests.
|
||||
requests. The default discovery/publication base is
|
||||
`https://example.com/.well-known/sshsigchain/`; publish bundles contain
|
||||
`allowed_signers`, `geth.sigchain.jsonl`, `geth.sigchain.checkpoint.json`, and
|
||||
`geth.sigchain.checkpoint.json.sig`. Clients can verify checkpoints, fetch
|
||||
bundles, import verified sigchains, and remember the last accepted checkpoint to
|
||||
reject older static bundles from the same source. `keychain fetch --url` is the
|
||||
retrieval location, so local `file://` mirrors work for testing; the signed
|
||||
checkpoint still records the advertised publication base URL, and
|
||||
`verify-checkpoint --base-url` can pin that value when needed.
|
||||
|
||||
Signing is mediated by OpenSSH. `--signing-key` may point at a private key file,
|
||||
a FIDO/YubiKey OpenSSH security-key stub, or a public key whose private half is
|
||||
available in `ssh-agent`. For encrypted private keys, the recommended workflow
|
||||
is to unlock the key with `ssh-add` and pass the public key path. For PKCS#11
|
||||
tokens, load the key into `ssh-agent` with `ssh-add -s <provider>` and use the
|
||||
exported public key path; direct PKCS#11 signing is not exposed by
|
||||
`ssh-keygen -Y sign` in a portable way.
|
||||
|
||||
The enrollment flow for a new node is:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue