Verify SSH host key in remote-exec provisioner

[jcassee]

Terraform Version

Terraform v0.11.2
+ provider.aws v1.8.0
+ provider.digitalocean v0.1.3
+ provider.hcloud (unversioned)

Your version of Terraform is out of date! The latest version
is 0.11.3. You can update by downloading from www.terraform.io/downloads.html

Terraform Configuration Files

resource "digitalocean_droplet" "test" {
  image      = "ubuntu-16-04-x64"
  name       = "test.example.com"
  region     = "ams3"
  size       = "1gb"
  user_data  = "#cloud-config\nssh_keys:\n  rsa_private: ...\n  rsa_public: ...\n"
}

Expected Behavior

It would be nice to be able to tell Terraform that the droplet has a known SSH hostkey, Cloud-init's write_files could be used to upload a SSH hostkey certificate too. In that case Terraform could be told to verify the certificate.

References

• A post on Hacker News about the plan to implement SSH certificate authentication
• Me asking this question on the Google Group

[jbardin]

Hi @jcassee,

Thanks for opening the issue! Sorry to keep you hanging here.
It appears that while the work was planned, due to some project turnover it was inadvertently left behind.

I have some patches in the works to resurrect host key verification, and we should be able to get this missing feature in for an upcoming release.

[jcassee]

No problem, @jbardin. Great to see your pull request.

One thing I am worried about is getting a known hostkey on the system. The only easy way I see is using user_data, but that data is 1) printed to the console in some cases and 2) stored in the state, which is usually not encrypted on disk (#9556, #17198). But I guess this is technically an orthogonal issue.

[berney]

What is the security risk of the SSH public key being printed on the console or saved in terraform state? If I had to choose between having the server's public key known (to attackers) vs not authenticating the server you are talking two - I know which one I'd prefer.

[jcassee]

The provisioned host requires both a public and corresponding private host key. So uploading one through user_data means including the private key.

Alternatively, you need to get the public key to Terraform after it was generated, but I don't know any method of doing so without using some central location (and how to authenticate the new host to that location?).

[berney]

I see. Thanks for the explanation and clearing up my misunderstanding. 👍

[jbardin]

Hi @jcassee,

Yes, getting the credentials onto the host to be provisioned is entirely an orthogonal issue, and not one that Terraform will directly handle.

Besides user_data, which has the drawbacks you mentioned, you could also bake it into the AMI, or have the host pull the key pair from a secure location. The scenario I prefer is to have the new host create its own keys like usual, then contact a signing service (e.g. the Vault ssh host signer) to sign its public key during initialization.

I mentioned it in the PR, but the provisioner is still somewhat limited when using signed keys, because the connection is made to the IP address by default (at least I think most providers send just the IP address), so the authority needs to be set on the IP address. If the authority is for a host or domain, the provisioner will need to be delegated to a null_resource to pass in the correct name.

[jcassee]

Sounds good, @jbardin. It's certainly something I can work with.

[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.