Strange "SSH_AUTH_SOCK is not set" error

[neuroserve]

root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~/triton-terra# ../terraform-0.10.6/terraform -v
Terraform v0.10.6

I'm going through https://www.joyent.com/blog/updates-to-triton-terraform-provider thus I'm trying to use the terraform provider for triton:

root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~/triton-terra# ../terraform-0.10.6/terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration, so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking changes, it is recommended to add version = "..." constraints to the corresponding provider blocks in configuration, with the constraint strings suggested below.

• provider.triton: version = "~> 0.2"

Terraform has been successfully initialized!

Actual Behavior

root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~/triton-terra# ../terraform-0.10.6/terraform plan -out ./tf.plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage.

Error refreshing state: 1 error(s) occurred:

• provider.triton: Error Creating SSH Agent Signer: SSH_AUTH_SOCK is not set

Expected Behavior

I would have expected, that terraform would create a plan.

Steps to Reproduce

See above. Is there a requirement to run ssh-agent on the box you use terraform?

Important Factoids

I'm logging in from a Laptop which is running ssh-agent into a vm which is just running sshd. I'm working against an on-premises setup of Triton - not the Joyent Cloud.

As the relevant debug-output is pretty short:

2017/09/25 07:27:14 [TRACE] dag/walk: walking "var.redis_install_script" 2017/09/25 07:27:14 [TRACE] vertex 'root.var.redis_install_script': walking 2017/09/25 07:27:14 [TRACE] vertex 'root.provider.triton': evaluating 2017/09/25 07:27:14 [TRACE] [walkRefresh] Entering eval tree: provider.triton 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalSequence 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalInitProvider 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalNoop 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalNoop 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalOpFilter 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalSequence 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalGetProvider 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalInterpolate 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalBuildProviderConfig 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalSetProviderConfig 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalOpFilter 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalSequence 2017/09/25 07:27:14 [TRACE] root: eval: terraform.EvalConfigProvider 2017/09/25 07:27:14 [ERROR] root: eval: terraform.EvalConfigProvider, err: Error Creating SSH Agent Signer: SSH_AUTH_SOCK is not set 2017/09/25 07:27:14 [ERROR] root: eval: terraform.EvalSequence, err: Error Creating SSH Agent Signer: SSH_AUTH_SOCK is not set 2017/09/25 07:27:14 [ERROR] root: eval: terraform.EvalOpFilter, err: Error Creating SSH Agent Signer: SSH_AUTH_SOCK is not set 2017/09/25 07:27:14 [ERROR] root: eval: *terraform.EvalSequence, err: Error Creating SSH Agent Signer: SSH_AUTH_SOCK is not set 2017/09/25 07:27:14 [TRACE] [walkRefresh] Exiting eval tree: provider.triton

All code has been cutted and pasted from the example above. Nothing has been added so far. This is the first error in the first run.

[neuroserve]

OK - verified. Maybe it's just a documentation omission: Starting ssh-agent, exporting SSH_AUTH_SOCK and adding the required ssh-key via ssh-add to ssh-agent removes the error message.

[jwreagor]

@neuroserve Sounds like the provider is working for you now that you have ssh-agent setup.

I wrote the blog article and assumed configuration using Triton's normal SSH based authentication with ssh-agent configured with your Triton key (what the triton CLI process walks through).

There are manual options for configuring provider {} documented on Terraform's website. Is there any other place where you think we could document better?

[neuroserve]

I'm not sure to what you refer by "what the triton CLI process walks through" - as far as I understand (and that's the reason why this error took me by surprise) ssh-agent was not part of the triton cli setup until now. I was using the triton cli quite happily on the same machine I was using for that terraform example - without a running ssh-agent. "triton env us-west-1" just exports SDC_KEY_ID and does not ssh-add it to a running ssh-agent instance. Or is there a "new" way of setting up triton cli, that I'm not aware of?

[jwreagor]

No you’re right, I had forgotten it references the actual file system location and not through the agent. I’ll make an adjustment on the blog entry and also in the README of this project. Appreciate it!

EDIT: I'll keep this issue open until I've got the changes squared away.

[jwreagor]

@neuroserve Let me know if that PR addresses my documentation fault and I'll port the same to the blog post.

[jwreagor]

The PR should alleviate issues in the future. Thanks for helping out!