These are skipped without the SSH_UPLOAD_TEST flag, since they require
connecting to a running ssh server on localhost as the current user, and
one creates a very large file.
Fixes#10463
I'm really surprised this flew under the radar for years...
By having unique PRNGs, the SSH communicator could and would
generate identical ScriptPaths and two provisioners running in parallel
could overwrite each other and execute the same script. This would
happen because they're both seeded by the current time which could
potentially be identical if done in parallel...
Instead, we share the rand now so that the sequence is guaranteed
unique. As an extra measure of robustness, we also multiple by the PID
so that we're also protected against two processes at the same time.
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.
Without a seed, the "random" script path locations for the remote-exec
provisioner were actually deterministic!
Every rand.Int31() would return the same pseudorandom chain starting w/
the numbers: 1298498081, 2019727887, 1427131847, 939984059, ...
So here we properly seed the communicators so the script paths are
actually random, and multiple runs on a single remote host have much
less chance of clobbering each other.
Fixes#4186
Kudos to @DustinChaloupka for the correct hunch leading to this fix!
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.
On connections where no second hop is made, there's no problem if the
agent forwarding connection is denied, so we shouldn't treat that as a
fatal error.
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.
I added a debug log line in the last commit, only to find out it’s now
logging the same info twice. So removed the double entry and tweaked
the existing once.
While fixing the vet warning also tried to improve any feedback by
showing the actual output/error instead of just the error code.
While testing this I noticed only adding stderr output is not enough as
not all error info is send to stderr, but sometimes also to stdout.
* 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…
James Bardin