Thales Maciel
ebe651762f
Bug: every daemon Open deleted the freshly-generated default SSH key
before returning, so the next VM create failed reading it.
Sequence:
1. Open → config.Load → resolveSSHKeyPath generates
~/.config/banger/ssh/id_ed25519
2. Open → ensureVMSSHClientConfig → syncVMSSHClientConfig scrubs
~/.config/banger/ssh entirely as a migration step for the
pre-opt-in layout (commit 108f7a0)
The scrub was added for a file that used to live at
ConfigDir/ssh/ssh_config, but it os.RemoveAll'd the whole
ConfigDir/ssh dir — including the id_ed25519 the key generator had
just put there.
Fix: point the default key at layout.SSHDir (a StateDir-rooted path
that paths.Ensure already creates). The scrub can keep cleaning up
ConfigDir/ssh because nothing banger writes under it anymore.
Users whose ssh_key_path is explicitly set in config.toml are
unaffected — configured wins. Users on the default path will get a
fresh key at StateDir/ssh/id_ed25519 on their next daemon Open;
existing VMs' authorized_keys re-sync on next start/create through
ensureAuthorizedKeyOnWorkDisk, so no manual intervention is needed
beyond restarting the daemon.
Regression test pins the new placement and asserts the legacy path
stays empty.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 line
81 B
Text
1 line
81 B
Text
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOpF+WjNdlBLZYI3sbPST2lhxzrsfELwRXT58vkNL3xK
|