thaloco/banger
1
Fork 0
Code Pull requests Releases Packages Activity Actions

README: describe the SSH-key migration as a VM restart, not workspace sync

Browse source 
The migration note said existing VMs needed a "fresh workspace
sync" to pick up a new host SSH key fingerprint. That's wrong:
workspace.prepare (vm workspace prepare) touches the git checkout,
not authorized_keys. The authorized_keys rewrite happens on the
vm start path — specifically in workDiskCapability.PrepareHost
calling WorkspaceService.ensureAuthorizedKeyOnWorkDisk, which runs
during start, not during an explicit workspace sync.

Rewrite the note to name the actual recovery action: stop-and-start
(or vm restart). Leave the --rm caveat — those flows always boot
fresh and don't carry the problem.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Thales Maciel 2026-04-22 18:06:52 -03:00
parent e2ac70631b
commit 52612b516b
No known key found for this signature in database
GPG key ID: 33112E6833C34679
1 changed files with 6 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

9
README.md
View file

@ -165,9 +165,12 @@ Full key list in `internal/config/config.go`.
> hardcoded in `config.toml`, either keep it (banger preserves the > hardcoded in `config.toml`, either keep it (banger preserves the
> directory when `ssh_key_path` points inside it) or unset the key > directory when `ssh_key_path` points inside it) or unset the key
> and banger will manage the new default for you. The first time the > and banger will manage the new default for you. The first time the
> daemon starts against the new default, guest VMs need a fresh > daemon starts against a new key, any already-running guest VMs
> workspace sync (`banger vm stop && start`, or `--rm` flows are > still carry the previous fingerprint in their `authorized_keys`.
> unaffected) so their `authorized_keys` pick up the new fingerprint. > Stop-and-start each VM (`banger vm stop <name> && banger vm start
> <name>`, or `vm restart`) to let the start-path reprovision the
> work disk with the new key. Fresh VMs and `--rm` flows are
> unaffected.
### `vm_defaults` — sizing for new VMs ### `vm_defaults` — sizing for new VMs