Provisioner Connection Settings

Most provisioners require access to the remote resource via SSH or WinRM and expect a nested connection block with details about how to connect.

~> Important: Use provisioners as a last resort. There are better alternatives for most situations. Refer to Declaring Provisioners for more details.

Connection Block​

You can create one or more connection blocks that describe how to access the remote resource. One use case for providing multiple connections is to have an initial provisioner connect as the root user to set up user accounts and then have subsequent provisioners connect as a user with more limited permissions.

Connection blocks don't take a block label and can be nested within either a resource or a provisioner.

• A connection block nested directly within a resource affects all of that resource's provisioners.
• A connection block nested in a provisioner block only affects that provisioner and overrides any resource-level connection settings.

Since the SSH connection type is most often used with newly-created remote resources, validation of SSH host keys is disabled by default. If this is not acceptable, you can establish a separate mechanism for key distribution and explicitly set the host_key argument (details below) to verify against a specific key or signing CA.

Example usage​

# Copies the file as the root user using SSH
provisioner "file" {
  source      = "conf/myapp.conf"
  destination = "/etc/myapp.conf"

  connection {
    type     = "ssh"
    user     = "root"
    password = "${var.root_password}"
    host     = "${var.host}"
  }
}

# Copies the file as the Administrator user using WinRM
provisioner "file" {
  source      = "conf/myapp.conf"
  destination = "C:/App/myapp.conf"

  connection {
    type     = "winrm"
    user     = "Administrator"
    password = "${var.admin_password}"
    host     = "${var.host}"
  }
}

The self Object​

Expressions in connection blocks cannot refer to their parent resource by name. References create dependencies, and referring to a resource by name within its own block would create a dependency cycle. Instead, expressions can use the self object, which represents the connection's parent resource and has all of that resource's attributes. For example, use self.public_ip to reference an aws_instance's public_ip attribute.

Argument Reference​

The connection block supports the following arguments. Some arguments are only supported by either the SSH or the WinRM connection type.

Connecting through a Bastion Host with SSH​

The ssh connection also supports the following arguments to connect indirectly with a bastion host.

Connection through a HTTP Proxy with SSH​

The ssh connection also supports the following fields to facilitate connections by SSH over HTTP proxy.

How Provisioners Execute Remote Scripts​

Provisioners which execute commands on a remote system via a protocol such as SSH typically achieve that by uploading a script file to the remote system and then asking the default shell to execute it. Provisioners use this strategy because it then allows you to use all of the typical scripting techniques supported by that shell, including preserving environment variable values and other context between script statements.

However, this approach does have some consequences which can be relevant in some unusual situations, even though this is just an implementation detail in typical use.

Most importantly, there must be a suitable location in the remote filesystem where the provisioner can create the script file. By default, OpenTF chooses a path containing a random number using the following patterns depending on how target_platform is set:

• "unix": /tmp/terraform_%RAND%.sh
• "windows": C:/windows/temp/terraform_%RAND%.cmd

In both cases above, the provisioner replaces the sequence %RAND% with some randomly-chosen decimal digits.

Provisioners cannot react directly to remote environment variables such as TMPDIR or use functions like mktemp because they run on the system where OpenTF is running, not on the remote system. Therefore if your remote system doesn't use the filesystem layout expected by these default paths then you can override it using the script_path option in your connection block:

connection {
  # ...
  script_path = "H:/opentf-temp/script_%RAND%.sh"
}

As with the default patterns, provisioners will replace the sequence %RAND% with randomly-selected decimal digits, to reduce the likelihood of collisions between multiple provisioners running concurrently.

If your target system is running Windows, we recommend using forward slashes instead of backslashes, despite the typical convention on Windows, because the OpenTF language uses backslash as the quoted string escape character.

Executing Scripts using SSH/SCP​

When using the SSH protocol, provisioners upload their script files using the Secure Copy Protocol (SCP), which requires that the remote system have the scp service program installed to act as the server for that protocol.

Provisioners will pass the chosen script path (after %RAND% expansion) directly to the remote scp process, which is responsible for interpreting it. With the default configuration of scp as distributed with OpenSSH, you can place temporary scripts in the home directory of the remote user by specifying a relative path:

connection {
  type = "ssh"
  # ...
  script_path = "opentf_provisioner_%RAND%.sh"
}