provider/digitalocean: ssh_keys doesn't update on digitalocean_droplet

[hashibot]

This issue was originally opened by @shirkevich as hashicorp/terraform#2733. It was migrated here as part of the provider split. The original body of the issue is below.

---

I'm trying to add second ssh key to working droplet, terraform output is ok, but in fact, second key is not provisioned:

digitalocean_droplet.docker: Modifying...
  ssh_keys.#: "1" => "2"
  ssh_keys.1: "" => "978405"

[hashibot]

This comment was originally opened by @cabbiepete as https://github.com/hashicorp/terraform/issues/2733#issuecomment-241158800. It was migrated here as part of the provider split. The original comment is below.

---

This is more of a DO thing than a terraform thing. DO only provisions ssh keys when you create droplets it never updates them post this. You can use a provisioner such as remote exec, chef, puppet to ensure the full list of keys is there.

[hashibot]

This comment was originally opened by @apparentlymart as https://github.com/hashicorp/terraform/issues/2733#issuecomment-241173801. It was migrated here as part of the provider split. The original comment is below.

---

Based @cabbiepete's comment, it sounds like the bug here is that we should have ForceNew set on that attribute so that Terraform knows that it has to create a replacement droplet in order to implement an SSH key change.

[hashibot]

This comment was originally opened by @cabbiepete as https://github.com/hashicorp/terraform/issues/2733#issuecomment-241176470. It was migrated here as part of the provider split. The original comment is below.

---

@apparentlymart I'd expect that to be an optional setting and default to not. There are other ways to get the new/updated ssh key to the server in less destructive ways which is a better default for anyone that does not quite know all the details of terraform and that particular provider.

[hashibot]

This comment was originally opened by @apparentlymart as https://github.com/hashicorp/terraform/issues/2733#issuecomment-241177273. It was migrated here as part of the provider split. The original comment is below.

---

@cabbiepete is there something that Terraform could do automatically/programmatically when it detects a diff on this attribute? ForceNew is how Terraform models things that can only be set at creation time and can't be updated later, so that's the right thing to do unless there's something less destructive that Terraform could do instead, to apply an update here.

Your earlier comment suggested that logging in to the machine and manually tweaking the keys was the only path. If so, this is a similar situation to Amazon EC2, where the corresponding attribute (key_pair) is marked as ForceNew as I described.

[hashibot]

This comment was originally opened by @danielsreichenbach as https://github.com/hashicorp/terraform/issues/2733#issuecomment-262935994. It was migrated here as part of the provider split. The original comment is below.

---

Adding my two cents here. I just did this on an existing droplet, where I needed to extend set of SSH keys deployed.

This is actually working, if you supply a connection object in the droplet configuration, and then add further entries to the SSH configuration.

[gdubicki]

What you mean by "supplying a connection object", @danielsreichenbach ? Can you share the code that is working for you?

[danielsreichenbach]

@gdubicki yes, of course.

resource "digitalocean_droplet" "example" {
  ssh_keys = [
    "${digitalocean_ssh_key.default.fingerprint}",
    "${digitalocean_ssh_key.example.fingerprint}",
  ]

  connection {
    user    = "root"
    type    = "ssh"
    timeout = "60s"
    agent   = true
  }
}

Supplying the connection settings resolved the issue of not updating SSH keys added/changed for me. Previously I only had ssh_keys set. We're using it like this for almost half a year on production systems with no problems.

[MasonEgger]

Closing this issue. Retroactively adding and removing SSH keys is not something the API allows us to do. I would recommend using a configuration management tool such as Ansible, Salt, or Puppet for managing identity past the initial provisioning step. The connection work around provided appears to work so that is another viable solution.