Deployment fails with Terraform Cloud

[JamesBelchamber]

When deploying a cluster following this guide using Terraform Cloud in Remote Execution Mode, the run fails with the following error:

timeout - last error: SSH authentication failed (core@<IP>:22): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain

This is implied by the ssh-agent part of the guide, but since it's not explicitly called out (and the guide is otherwise quite fleshed out) I had a go and.. yup, not gonna work without that key 😅

I'm gonna have a go and see if there's any way to make this work - based on the results I can propose a PR for the guide.

[8ball030]

I have this issue when trying to deploy to gcp at present.

Symptoms;

Timeouts when copying secrets for the controller.

 Error: file provisioner error
│ 
│   with module.yavin.null_resource.copy-controller-secrets[1],
│   on .terraform/modules/yavin/google-cloud/fedora-coreos/kubernetes/ssh.tf line 25, in resource "null_resource" "copy-controller-secrets":
│   25:   provisioner "file" {
│ 
│ timeout - last error: dial tcp 35.243.100.95:22: i/o timeout

Seems maybe to be an issue with the ssh agent.

@dghubble wonder if its work allowing the user to pass in the ssh key path?

Looks like it could be done in the;

ssh.tf files.

What do you think to including the variables;

agent: Set to false to disable using ssh-agent to authenticate. On Windows the only supported SSH authentication agent is [Pageant](http://the.earth.li/~sgtatham/putty/0.66/htmldoc/Chapter9.html#pageant).

and

private_key: The contents of an SSH key to use for the connection. These can be loaded from a file on disk using [the file function](https://developer.hashicorp.com/terraform/language/functions/file). This takes preference over password if provided.

as optional inputs for users?

Unfortunately this is kind of blocking me a little bit.

I believe there are probly a couple of fixes here on a host level however;

A) set the ssh-agent to use the correct identity. (Will update if i figure this out)

B) do some kind of hack to get the initial state.

I dont suppose you have seen this issue before?

[dghubble]

The usual thing to do is configure ssh-agent to know about your SSH keys. It's flexible and works whether you use Yubikeys or private keys on disk, and avoids needing to hardcode paths. It's a main purpose of ssh-agent.

https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent