Yeah, I just stumbled across the exact same issue. That would be very helpful in order to sign git commits.

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.

Think this is the right issue to comment on about my situation.

Running into a Chicken/Egg situation myself in my current project. Here's the scenario:

1. The workspace we are creating starts from a base VM image
2. In order to provision a dev environment, we need to clone a repository onto the VM once it's spun up and run a script from that repo which is responsible for creating the dev environment and includes cloning other repos onto the VM.
3. The dev env setup process requires the public key being used to clone the repos to be added to our users account in our git provider.

Current struggles

The current template is setup to use the Coder Agent startup_script and functionally this works but has some downsides that make the UX sub-optimal.

First, a relatively minor inconvenience, is the user has to add the new public key to all git hosts that they need to pull down repos from. This adds the overhead of having to manage another key across your providers in the event that something requires it to be changed.

The second, and more complicated situation, stems from having to run the setup script as the coder_agent startup script. In my current scenario, the meat of the "provisioning" process is running that script and because the workspace's status and available output is limited to the Terraform provisioning steps, we end up with workspaces that show to be deployed but do not have any way of seeing the output or status of our start up script to see if the dev environment was properly setup (Basically just have to wait for the interface to show the coder agent running and then login and check manually if things worked out).

Potential Solution Thoughts

The key being pregenerated by coder isn't really a problem but not having the ability to utilize those keys until the Coder Agent is running means that provisioning steps that would be best suited for inclusion in the Terraform run are not possible without having the user supply a private key directly to Terraform to use for any resources that would need them (which I'm personally opposed to).

I'm not sure what the best solution is here as I could see there being a number of ways of addressing it but I did have one workflow idea that made sense in my head.

The idea is to have an option in the coder_agent resource that directs it to install the private key into the workspace users home directory automatically as part of the startup process. Couple this with a new Terraform resource that simply waits for the coder agent to report that it's finished starting successfully (probably through an API call to the coder server), templates would then be able to make additional provisioning steps depend on this resource to ensure that when they run the users SSH key is installed on the system for them to make use of.

Sorry for the wall of text, wanted to take a break from working on the problem to brain dump here before jumping back into working on it again lol.

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.

bump

Any thoughts on reopening this? Or any other related issue that covers this case? @bpmct @sharkymark

Ah whoops - we plan on doing this. There is also a current workaround. See this (still open) issue: #5599