Add `host_key` and `bastion_host_key` fields to the ssh communicator
config for strict host key checking.
Both fields expect the contents of an openssh formated public key. This
key can either be the remote host's public key, or the public key of the
CA which signed the remote host certificate.
Support for signed certificates is limited, because the provisioner
usually connects to a remote host by ip address rather than hostname, so
the certificate would need to be signed appropriately. Connecting via
a hostname needs to currently be done through a secondary provisioner,
like one attached to a null_resource.
It's becoming more common for users to have many ssh keys loaded into an
agent, and with the default max auth attempts of an openssh server at 6,
one often needs to specify which id to use in order to avoid a `too many
authentication failures` error.
Add a connection field called `agent_identity` which will function
similarly to the ssh_config IdentityFile when used in conjunction with
an ssh agent. This uses `agent_identity` rather than `identity_file` to
specify that the file is not used directly for authentication, rather
it's used to choose which identity returned from the agent to
authenticate with first.
This feature tries a number of different methods to match the agent
identity. First the provisioner attempts to read the id file and extract
the public key. If that isn't available, we look for a .pub authorized
key file. Either of these will result in a public key that can be
matched directly against the agent keys. Finally we fall back to
matching the comment string exactly, and the id as a suffix. The only
result of using the agent_identity is the reordering of the public keys
used for authentication, and if there is no exact match the client
will still attempt remaining keys until there is an error.
Fixes#3605 and adds the functionality suggested in PR #7440.
This PR is using a different appraoch that (IMHO) feels cleaner and (even more important) adds support for Windows at the same time.
We've been moving away from config fields expecting file paths that
Terraform will load, instead prefering fields that expect file contents,
leaning on `file()` to do loading from a path.
This helps with consistency and also flexibility - since this makes it
easier to shift sensitive files into environment variables.
Here we add a little helper package to manage the transitional period
for these fields where we support both behaviors.
Also included is the first of several fields being shifted over - SSH
private keys in provisioner connection config.
We're moving to new field names so the behavior is more intuitive, so
instead of `key_file` it's `private_key` now.
Additional field shifts will be included in follow up PRs so they can be
reviewed and discussed individually.
In the SSH client configuration, we had SSH Agent authentication listed
before the static PrivateKey loaded from the `key_file` setting.
Switching the default of the `agent` setting exposed the fact that the
SSH agent overrides the `key_file` during the handshake. By listing the
`key_file` first, we catch the provided key before any query goes out to
the agent.
Adds a key-based authentication SSH test to cover this new behavior. It
fails without the reordering on any machine with an SSH agent running.
Fixes#2614
* adds `bastion_*` fields to `connection` which add configuration for a
bastion host
* if `bastion_host` is set, connect to that host first, then jump
through it to make the SSH connection to `host`
* enables SSH Agent forwarding by default
This changes SSH Agent utilization from opt-in to opt-out, bringing
Terraform in line with the behavior of Packer and the `ssh` command
itself.
But skip SSH agent connections if the SSH_AUTH_SOCK env var doesn't exist,
whcih means there's no agent to connect to.
* We now return an error when you set the script_path to
C:\Windows\Temp explaining this is currently not supported
* The fix in PR #1588 is converted to the updated setup in this PR
including the unit tests
Last thing to do is add a few tests for the WinRM communicator…
This is needed as preperation for adding WinRM support. There is still
one error in the tests which needs another look, but other than that it
seems like were now ready to start working on the WinRM part…
Fábio Matavelli