Stable identity
A VLAD remains stable while its keys and protected metadata rotate.
SSH with stable identity
VLAD-SSH
What VLAD-SSH Does
VLAD-SSH makes SSH trust plog-derived identity state. Instead of treating one copied public key as the permanent identity, a client or server follows a VLAD and resolves the current SSH key from the verified provenance log.
That means a user can rotate their SSH key, a server can rotate its host key, and authorized systems can converge after verification without sending a new key file to every machine by hand.
BetterSign supports both OpenSSH integration and an embedded SSH server path. The OpenSSH integration updates authorized_keys. The embedded server can use BetterSign capability discovery and VLAD-rooted host-key verification more directly.
See SSH key rotation in action — rotate once, and every host rewrites its authorized_keys automatically.
VLAD-SSH Login Path
Client knows user VLAD and target server information ↓
Local daemon resolves current user SSH key from verified plog ↓
Remote server follows authorized user VLADs ↓
Server resolves current accepted key material ↓
SSH authentication succeeds with current plog-authorized key
Watch It Work: Desktop Walkthrough
A screen recording of the BetterSign desktop app driving SSH — creating and managing the identity, and the keys behind it, from the UI.
Watch It Work: VLAD-SSH End to End
A full VLAD-SSH walkthrough: following a VLAD, resolving the current SSH key from the verified provenance log, and logging in — with the identity surviving a key rotation.
Client Flow
The bs ssh command can ask the local daemon to start a per-plog SSH agent for the identity named by --from-vlad. The CLI then uses the returned SSH_AUTH_SOCK for the connection.
When --vlad and --peer-multiaddr are supplied, the CLI can discover remote SSH capabilities from the BetterSign peer: SSH port, key path, and supported key exchange policy. Operator-specified flags still win.
This avoids the normal ritual of manually loading an id_ed25519 file into a global agent. The credential comes from the selected BetterSign identity and can rotate through the plog.
bs-server startbs ssh <host> -l <user> --from-vlad <CLIENT_VLAD_HEX> --vlad <SERVER_VLAD_HEX> --peer-multiaddr <SERVER_MULTIADDR>bs ssh-agent statusbs ssh-agent start <LOG_ID>eval $(bs ssh-agent export)Server Flow
On a server, BetterSign tracks trusted user VLADs and updates the managed section of the target authorized_keys file after verified plog changes.
The SSH handler resolves a configured key path, follows one level of plog path indirection when needed, converts Multikey bytes into an OpenSSH public-key line, and tags each managed line with the source VLAD.
Unmanaged authorized_keys lines are preserved. BetterSign rewrites only its marked managed section, so operators can keep local break-glass keys or unrelated entries outside the managed block.
authorized_keys Update
Tracking loop verifies followed user plog ↓
Build current key-value state from accepted entries ↓
Resolve configured SSH key path ↓
Convert Multikey to OpenSSH public key ↓
Rewrite BetterSign managed section ↓
Preserve unmanaged local entries
Plog Paths
The default server key path can point at a dedicated SSH key path or indirectly at a general identity key. This makes early setups simple while still allowing later separation between identity signing and SSH login keys.
A common structure is /data/ssh/server or /data/ssh/sign pointing to /keys/primary. As a deployment matures, the SSH path can be changed to a dedicated SSH-compatible Multikey without changing the VLAD.
If a specific SSH key path is missing, the server-side resolver can fall back to /data/ssh/sign and then /keys/primary when suitable key material is present.
Common SSH Paths
Path indirection lets policy move without changing every consumer.
- /keys/primary
- general identity signing key and final fallback for SSH-compatible identities
- /data/ssh/sign
- direct SSH signing key path used by SSH templates
- /data/ssh/server
- default server-side key path that may reference another plog path
- ssh.users
- server config mapping tracked VLADs to authorized_keys targets
Host Identity
VLAD-SSH can also bind a server host key to a server VLAD. A client can discover the server SSH subsystem information from the BetterSign peer and verify the advertised host key against plog-derived state instead of falling back to TOFU alone.
Subsystem VLADs let a server distinguish its administrative identity from the SSH server identity. The parent identity can cross-sign or advertise the subsystem so clients can follow the correct plog for host-key verification.
Host-Key Verification
Client targets server VLAD ↓
Capability discovery returns SSH subsystem details ↓
Client syncs server or subsystem plog ↓
Client resolves current host key path ↓
SSH host key is accepted only if it matches verified plog state
Rotation Behavior
SSH key rotation becomes a plog append. The owner publishes new key material at the relevant path, signs the update with the current authorized key or recovery key, and peers verify the new head.
Followers that manage authorized_keys rewrite their managed section after the verified change lands. Clients using a per-plog agent can use the new key without reconfiguring every remote server manually.
SSH Key Rotation
Generate replacement SSH-compatible key ↓
Append plog update at /data/ssh/sign or configured path ↓
Sign update with authorized primary or recovery key ↓
Tracking servers verify new plog head ↓
authorized_keys managed section is rewritten