encrypted ssh keys with ssh-agent no longer works on 0.6.7

[mentalstring]

On 0.6.6 it was possible to use a passphrase protected ssh key simply by setting private_key with a key contents through $file("") — then the local ssh-agent would take care of the rest. On 0.6.7 however it seems that is now impossible to use passphrase protected keys which seems a drop in functionality.

On 7ffa66d the goal seemed to be to move away from paths into using $file() which on itself is fine— that's how we were using it anyway already. But now it's checking if the key used is encrypted and aborts if it is.

Can't the check for if the key is encrypted be removed so that passphrase protected keys can continue being used like until 0.6.6?

[jen20]

Hi @mentalstring, for clarity, do you want to use pass-phrase protected keys for provisioner connections?

[mentalstring]

@jen20 Yes, that's right. Was working fine, but updating to 0.6.7 seems to make it impossible, unless I'm missing something.

Also tried with deprecated key_file, but the check for if it is an encrypted key doesn't allow ssh-agent to do its thing like it was doing before.

[lkwg82]

+1

[timmytofu]

I'm seeing this on 0.7.4 as well.

1 error(s) occurred:

* Failed to read key "-----BEGIN RSA PRIVATE KEY-----\n…": password protected keys are
not supported. Please decrypt the key prior to use.

it's reading the encrypted key file rather than using the agent despite agent = true

[leowmjw]

Any news on this? Bug still present in latest v0.9.2 👎

[apparentlymart]

Hi all! Sorry for the lack of movement here.

The intent with the agent option is for no credentials to be explicitly provided to Terraform at all. The private key is instead kept in the memory of the agent and auth challenges relayed by Terraform to the agent.

So I would expect that the private_key argument would not be set at all when agent = true. Terraform ought to fail with a helpful message if these two arguments are used together.

Can someone on this thread confirm if things work as expected if the private_key option is left unset? If so, I think we should just clarify this in the docs and implement a helpful error message for this situation.

[leowmjw]

@apparentlymart Thanks for the clarification. Here's the result of the two scenarios I tried; unfortunately without success :(

I am able to ssh to the node directly though (only provisioning fails); password-less and using the ssh-agent. This is on OSX and with Azure.

leow$ ssh testadmin@10.0.42.4
The authenticity of host '10.0.42.4 (10.0.42.4)' can't be established.
RSA key fingerprint is 6b:7e:d3:ea:72:1a:de:1d:49:c3:61:fc:eb:1b:28:6c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.42.4' (RSA) to the list of known hosts.
Welcome to Ubuntu Zesty Zapus (development branch) (GNU/Linux 4.10.0-14-generic x86_64)
..

Scenario #1: Unencrypted ssh key with agent set to false:

..
  provisioner "file" {
    connection {
      user = "testadmin"
      private_key = "${file("/tmp/ssl.key")}"
      agent = "false"
    }
    source = "../../lxd/scripts"
    ..

Result:

Error applying plan:
1 error(s) occurred:

* module.experiment.azurerm_virtual_machine.experiment_node: 1 error(s) occurred:
* dial tcp :22: getsockopt: connection refused

Scenario #2: No private_key set, agent set to true:

..
  provisioner "file" {
    connection {
      user = "testadmin"
      # private_key = "${file("/tmp/ssl.key")}"
      agent = "true"
    }
    source = "../../lxd/scripts"
    ..

Result:

Error applying plan:
1 error(s) occurred:
* module.experiment.azurerm_virtual_machine.experiment_node: 1 error(s) occurred:
* dial tcp :22: getsockopt: connection refused

[jen20]

This isn't a problem with authentication - your connection is not making it to that stage. I would instead investigate why there is no IP address associated with your connection.

[leowmjw]

@jen20 any commands or tools you suggest I run? As mentioned, I can SSH into the node just fine.

Which part of the code you reckon I should check out?. I'll try to dig into that part in the azurerm provider code base.

[apparentlymart]

@leowmjw it seems like there's something strange about your environment that isn't visible from what you shared, if ssh is able to reach your target host but Terraform's internal SSH is not. As @jen20 said, the errors from Terraform indicate a connectivity problem rather than an authentication problem.

There are lots of different variables here so it's hard for me to guess what might be going on, but my first idea would be to check if you have anything in ~/.ssh/config (or a system-wide equivalent file) that overrides how ssh would connect to that host. For example, perhaps there is some sort of proxy or bastion server in use. Terraform doesn't itself run the ssh command -- it has its own built-in SSH client -- so it will not pay attention to what's in ~/.ssh/config and any special settings in there must be set explicitly in the connection block of the Terraform config.

Github issues is not a great place to do troubleshooting and your situation seems to be outside of the scope of this issue, so if you are still having problems I would ask you to send further questions/information to the mailing list or Gitter chat, both of which are linked from the community page. Thanks!

[leowmjw]

Just for completeness, as pointed out the problem was connectivity; need to specify the host ip address specifically (I deploy via poor man's VPN sshuttle) as per below:

provisioner "file" {
    connection {
      host = "${element(azurerm_network_interface.experiment_netif.*.private_ip_address, count.index)}"
      user = "testadmin"
      agent = "true"
    }
    source = "../../lxd/scripts"
    destination = "/tmp"
  }

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.