Skip to content

Upgrade Guide: v0.7.0 to v0.7.1

v0.7.1 replaces v0.7.0's opt-in hardening bundle with a single secure-by-default switch and makes HTTP tokens automatic: they are minted on demand over an SSH bootstrap channel, short-lived, and refreshed/revoked for you. Tailscale / LAN stays the primary, unchanged path.

A breaking patch

This is a 0.7.x patch that carries breaking config changes — the interface is still settling in the 0.7 line. Most users are unaffected: the default is auth.mode: open, byte-for-byte the v0.7.0 trusted-network posture, so a tailnet/LAN config that never set public_exposure or auth.http.tokens keeps working after upgrading. The changes below only affect v0.7.0 deployments that enabled the public-exposure bundle or static HTTP tokens.

What changed

  • Binary auth.mode: open | secure replaces the public_exposure flag. secure derives the whole bundle (SSH allowlist enforced + HTTP tokens enforced + pinned TLS + loopback plain-HTTP) and refuses to start without an SSH key source.
  • Tokens are minted over SSH, not configured. A client with an allowlisted key mints a scoped token over the reserved _bootstrap SSH channel; shed server add does it automatically. There is no shed-server token new and no static auth.http.tokens list.
  • Short TTL + automatic refresh. Tokens expire (auth.token_ttl, default 24h); the CLI, host-agent, and desktop refresh transparently near expiry and on a 401. The host-agent mints its own credentials token — no credentials_token in client config.
  • Revocation follows the allowlist. Removing a key from the SSH allowlist purges its tokens on the next authoritative refresh.
  • The admin scope is removed — control and credentials only.

See Security for the full model and Public VPS Deployment for the end-to-end flow.

Breaking: removed keys now hard-fail

These v0.7.0 keys are rejected at startup in v0.7.1 — the server names the key and exits. Edit your server config before upgrading an internet-facing host, or it will fail to restart:

v0.7.0 (removed) v0.7.1 replacement
public_exposure: true auth.mode: secure (derives the same bundle).
auth.http.tokens: [...] Minted over SSH by shed server add; delete the list.
admin token scope Use control + credentials.
shed-server token new Removed — issuance is automatic.
client servers.<name>.credentials_token Removed — the host-agent self-mints.

Migrating a v0.7.0 secure deployment

  1. Server. Replace the bundle with the switch:
# before (v0.7.0)
public_exposure: true
auth:
  ssh: { mode: enforce, github_users: [charliek] }
  http:
    mode: enforce
    tokens:
      - { name: cli, scope: control, token: shed_control_xxxxx }
https_port: 8443

# after (v0.7.1)
auth:
  mode: secure
  ssh: { github_users: [charliek] }
tls_names: [shed.example.com]
  1. Clients. Static tokens are gone, so re-run shed server add once per server to re-pin TLS and mint a fresh token:
shed server add shed.example.com --https-port 8443

Then drop the old control_token / credentials_token lines from ~/.shed/config.yaml — server add writes the new control_token + control_token_expires_at, and the host-agent mints its own credentials token.

  1. Companion releases. The work spans three repos and must deploy in order — server, then host-agent, then desktop (a new host-agent must not bootstrap an old server). Upgrade shed-server first, then the matching shed-extensions host-agent and shed-desktop releases (see the release notes for exact versions). An open-mode server keeps the v0.7.0 host-agent and desktop working unchanged.

Coming from v0.6.x?

Going straight from v0.6.x to v0.7.1, read the v0.6 → v0.7 guide for context on the original auth/TLS surface, then note that v0.7.1 replaces its public_exposure / token new / auth.http.tokens steps with auth.mode: secure and the one-line shed server add flow in the VPS deployment guide.