Add SSH cert flows and user service installer

docs/adr/0001-single-binary-cli-and-daemon.md

@@ -12,7 +12,13 @@ The project ships one executable: `geth`. It has daemon mode with
 Control commands use a local Unix socket. There are no separate `gethd` or
 `gethctl` binaries.
 
+The same binary also owns daemon service installation through `geth daemon
+service ...`. Service installation targets user service managers: systemd user
+units on Linux, launchd user agents on macOS, and per-user scheduled tasks on
+Windows.
+
 ## Consequences
 
 Packaging and user mental model stay simple. The daemon remains the owner of
 identity, Iroh endpoint state, resources, and synchronized data structures.
+The bootstrap avoids privileged system service installation.

docs/adr/0009-ssh-trust-and-ssh-proxy.md

@@ -10,7 +10,16 @@ SSH keys are admin signing identities and ecosystem integration points. SSH is
 not a geth transport. Future SSH proxy support will carry SSH protocol bytes over
 authorized Iroh streams, and OpenSSH will still perform normal login auth.
 
+Geth also manages OpenSSH certificate request, renewal, approval, import, and
+revocation-list metadata. Signing is explicit: an approved request yields a
+concrete `ssh-keygen -s ...` command that can be run on the machine holding the
+CA key or attached YubiKey.
+
 ## Consequences
 
 Knowing an Iroh EndpointID is insufficient to reach sshd. Geth authorization must
 allow `ssh_proxy.connect` before any SSH/admin endpoint is opened.
+
+Certificate and key revocations are durable geth metadata and should be
+distributed over Iroh between authorized nodes. Discovery does not grant trust in
+certificate requests, issued certificates, or revocation lists.

docs/adr/0014-ssh-certificate-flows.md

@@ -0,0 +1,39 @@
+# ADR 0014: SSH Certificate Flows And Revocation Lists
+
+## Status
+
+Accepted.
+
+## Decision
+
+Geth manages OpenSSH certificate request, renewal, approval, import, and
+revocation-list metadata.
+
+A node may request a user or host certificate by submitting its public key,
+principals, requested validity, and optional renewal target. An authorized
+machine can approve that request. Approval does not silently sign inside the
+daemon; it returns an explicit `ssh-keygen -s ...` command that can be run on the
+machine with the CA private key or YubiKey-backed CA key. The resulting
+`-cert.pub` file is imported back into geth for distribution.
+
+Certificate and key revocations are durable records. The bootstrap stores and
+exports them as JSONL. Future work may derive OpenSSH KRL files and replicate
+signed revocation lists over Iroh.
+
+## Consequences
+
+SSH certificate lifecycle management becomes part of the SSH trust integration
+layer without making SSH a geth transport. The daemon can coordinate requests and
+distribution while the CA/YubiKey machine remains the explicit signing point.
+
+Future authorization should protect capabilities such as:
+
+- `ssh_cert.request`
+- `ssh_cert.approve`
+- `ssh_cert.import`
+- `ssh_revocation.publish`
+- `ssh_revocation.read`
+
+The current bootstrap does not claim that revocation reaches offline nodes
+immediately. Revocation distribution is eventual until stronger synchronization
+and policy enforcement are implemented.

docs/adr/0015-user-service-installation.md

@@ -0,0 +1,29 @@
+# ADR 0015: User Service Installation
+
+## Status
+
+Accepted.
+
+## Decision
+
+Geth provides `geth daemon service ...` commands to install, uninstall, start,
+stop, inspect, and print daemon service definitions.
+
+The service is always installed as a user service:
+
+- Linux: systemd user unit, `~/.config/systemd/user/geth.service`
+- macOS: launchd user agent, `~/Library/LaunchAgents/local.geth.daemon.plist`
+- Windows: per-user scheduled task named `geth-daemon`
+
+The service runs the same single binary as `geth daemon run` and preserves
+`GETH_HOME` in the service environment.
+
+## Consequences
+
+There are still no separate `gethd` or `gethctl` binaries. Installation does not
+require privileged system service access. Linux users who need the daemon before
+interactive login may still need platform-specific user-service setup such as
+systemd lingering.
+
+Future service managers can be added behind the same service-manager enum and
+CLI shape.

docs/architecture.md

@@ -6,6 +6,12 @@ the future shared Iroh endpoint, resource registry, module routing, and local
 control socket. Control commands connect to the Unix socket and send typed JSONL
 requests.
 
+Service management is also exposed through the single binary. `geth daemon
+service ...` installs and controls a user-level service definition for the local
+daemon. The initial backends are systemd user units on Linux, launchd user agents
+on macOS, and per-user scheduled tasks on Windows. Geth does not install itself
+as a privileged system service.
+
 ## Iroh-Only Remote Communication
 
 Remote geth node-to-node communication is Iroh-only. The daemon will own one
@@ -17,6 +23,13 @@ identities for keychain and authorization operations. SSH proxying, when added,
 will carry SSH bytes over an authorized Iroh stream and will not make SSH a geth
 transport backend.
 
+SSH certificate flows use the same split. Nodes can request new OpenSSH
+certificates or renewals through geth metadata. A machine with the CA key or
+YubiKey can approve the request and run an explicit `ssh-keygen -s ...` command,
+then import the resulting certificate for distribution. Certificate and key
+revocations are stored as signed-list-ready records and will be replicated over
+Iroh in later phases.
+
 ## Resource Model
 
 Everything meaningful is modeled as a resource. Resources have a kind, name,
@@ -42,6 +55,11 @@ are future work.
 `geth-kv`, `geth-db`, `geth-document`, `geth-pubsub`, `geth-pipe`, and
 `geth-ssh-proxy` currently define types, command shape, and roadmap stubs.
 
+`geth-ssh-identity` defines SSH trust namespaces plus certificate request,
+approval, certificate import, and revocation-list data models. The bootstrap
+persists these flows locally and exports revocations as JSONL. It does not yet
+generate OpenSSH KRL binaries or replicate the lists over Iroh.
+
 ## Keychain, Auth, And Secrets
 
 The identity plane is `geth-keychain`: admin keys, users, devices, nodes, agents,
@@ -85,4 +103,10 @@ strong forward secrecy or post-compromise security.
 - Bearer secrets are resource-scoped capabilities.
 - Bearer access does not imply trust graph mutation rights.
 - Authorization is capability-based and resource-scoped.
+- SSH certificate issuance must be explicitly approved by an authorized
+  principal before signing.
+- SSH certificate and key revocations are durable metadata that should be
+  distributed over Iroh, not fetched through unauthenticated discovery.
 - Network and control decoders treat input as untrusted.
+- Service installation targets user service managers, not system service
+  managers.

docs/roadmap.md

@@ -7,6 +7,7 @@
 - local store
 - local identity
 - local CAS
+- user service installer for systemd, launchd, and Windows scheduled tasks
 - docs and ADRs
 
 ## Phase 1: Iroh Foundation
@@ -16,10 +17,14 @@
 - peer discovery
 - peer exchange
 - basic authenticated peer connection
+- additional user service manager backends where useful
 
 ## Phase 2: Trust And Authorization
 
 - SSH-admin-rooted keychain
+- SSH certificate request and renewal queues
+- CA/YubiKey approval workflow
+- certificate and key revocation-list records
 - signed keychain ops
 - resource auth ops
 - grants and revocations
@@ -39,6 +44,8 @@
 - dumbpipe-style streams
 - TCP and Unix socket forwarding
 - SSH proxy over Iroh
+- SSH certificate and revocation distribution over Iroh
+- OpenSSH KRL export/import support
 - restricted geth admin shell
 
 ## Phase 5: DB And Documents