smoke: the vm key is 0600 before ssh is asked to use it

Run 7 finally booted the guest all the way to a login prompt — the
console karg fix held — and still died waiting for ssh. The reason was
waiting in the kept artifacts: the throwaway key on disk is 0644, and
ssh refuses a world-readable private key outright. The smoke runs as
root with BatchMode, so the refusal was swallowed and the stage read
as 'no ssh within 1800s' while the guest sat at its prompt, reachable
and willing, for half an hour.

Two layers now enforce what should never have depended on whoever
wrote the file first: kuma vm sets the mode on the private key
whatever its age (a reused VM directory must heal, not inherit), and
the boot stage chmods the key at the use site, so an artifact kept by
an older binary still works.

Author: Letdown2491

scripts/smoke.sh

@@ -3203,7 +3203,10 @@ smoke_boot() {
     local ssh_opts=(-p "$port" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
                     -o ConnectTimeout=5 -o LogLevel=ERROR -o BatchMode=yes)
     # `kuma vm` writes this only when the host had no key of its own.
-    [ -f "$dir/ssh-key" ] && ssh_opts+=(-i "$dir/ssh-key")
+    # A kept key may predate the 0600 rule: ssh refuses a world-readable
+    # private key outright ("bad permissions", which BatchMode then
+    # swallows), so heal the mode here rather than trust whoever wrote it.
+    [ -f "$dir/ssh-key" ] && chmod 600 "$dir/ssh-key" && ssh_opts+=(-i "$dir/ssh-key")
     ssh_opts+=(kuma@127.0.0.1)
     # shellcheck disable=SC2029  # client-side expansion is the point: every
     # caller builds the command here and wants the guest to run it literally.

src/main.rs

@@ -4104,6 +4104,16 @@ fn vm_ssh_key(output: &Path) -> Option<String> {
         ])
         .ok()?;
     }
+    // The private half is only ever meant for the caller of this
+    // command, whoever that is: a key that ships world-readable makes
+    // ssh refuse it outright — "bad permissions" — and the VM
+    // unopenable over its own key. Heal rather than assume, because
+    // the key may predate this run (a reused VM directory) and
+    // whatever wrote it may not have agreed on the mode.
+    use std::os::unix::fs::PermissionsExt;
+    let mut perms = std::fs::metadata(&private).ok()?.permissions();
+    perms.set_mode(0o600);
+    std::fs::set_permissions(&private, perms).ok()?;
     std::fs::read_to_string(&public).ok()
 }