fix: enable running rekey in a non-interactive shell

[bkabrda]

This PR fixes an issue of rekeying in a non-interactive shell.

With the current code, EDITOR will be set to cp -- /dev/stdin in a non-interactive shell and hence the CLEARTEXT_FILE will be overwritten with an empty string - effectively erasing the secret value. This PR fixes that by only calling editor if we're not rekeying.

[cole-h]

Could you re-push to hopefully see all CI passing?

[bkabrda]

@cole-h done. The only way I could think of to retrigger CI from my side was pushing an empty commit - if you decide to accept this PR, it'd probably be best to squash the commits to a single one to not have unnecessary empty commit in the main branch. Thanks!

[bkabrda]

Hmm, the check is still failing with:

       last 10 log lines:
       > !!! Traceback (most recent call last):
       > !!!   File "<string>", line 10, in <module>
       > !!!     system1.wait_until_tty_matches("2", "login: user1")
       > !!! 
       > !!! RequestedAssertionFailed: action timed out after 900 tries with one-second pause in-between
       > cleanup
       > kill machine (pid 9)
       > qemu-system-x86_64: terminating on signal 15 from pid 6 (/nix/store/h097imm3w6dpx10qynrd2sz9fks2wbq8-python3-3.12.11/bin/python3.12)
       > kill vlan (pid 7)
       > (finished: cleanup, in 0.00 seconds)

I don't think this is caused by my PR... should I try one more empty commit to retrigger?

[cole-h]

That's not necessary; I can run the CI job now. (The old run was too old; GitHub doesn't let you restart too old runs.)

First, however, you might want to try to rebase on the latest main.

[bkabrda]

@cole-h I might be looking wrong, but I think my branch already is on top of latest main

[n8henrie]

EDIT: Wrong thread

[RileyMathews]

Sorry to kind of but in here on this convo but I actually just ran into this today when trying out automating adding new nix VMs to my proxmox home server. I currently use agenix and got tired of the manual setup process of having to copy in new VM host keys to my local config every time before being able to deploy secrets. I'm also partially trying to automate this using opencode agents/skills so that I have the benefit of having an LLM do some of the more tedious work of making a new VM entry in my flake.nix file and generating the initial boilerplate of configuration.nix for my new VM. When I get to the point of grabbing the new host ssh key and rekeying I hit this issue because the opencode shell is not interactive.

I know I probably shouldn't be allowing an LLM anywhere around this and I'm totally fine to just adjust my scripts and agents to be mostly automated but having to manually run rekey myself during the setup process. But this is perhaps one other use case that could be considered.

[bkabrda]

@n8henrie I'm not sure I follow - this is independent of #361 and addresses a different usecase, which is running rekey in a non-interactive shell. What potential new vulnerability do you see in this PR?

[n8henrie]

@bkabrda yup -- wrong thread, too many tabs open. Thanks!

[cole-h]

@cole-h I might be looking wrong, but I think my branch already is on top of latest main

Oops, you're right. I could have sworn there were newer pushes, but I guess not! Guess it just needed a restart; thanks!

[bkabrda]

Thank you both!