Connection blocks for SSH in Terraform - Commands & Configuration

Introduction

When Terraform needs to connect to a remote server to run commands or copy files, it uses connection blocks. These blocks tell Terraform how to connect using SSH, like giving it the server address, username, and key. This helps automate tasks on remote machines.

When you want Terraform to run setup commands on a new virtual machine after creating it.

When you need to copy configuration files from your local machine to a remote server during deployment.

When you want to automate software installation on a remote server using Terraform.

When you manage infrastructure that requires secure SSH access for provisioning.

When you want to avoid manual SSH login and automate remote tasks in your Terraform scripts.

Config File - main.tf

main.tf

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("~/.ssh/id_rsa")
    host        = self.public_ip
  }

  provisioner "remote-exec" {
    inline = [
      "sudo yum update -y",
      "sudo yum install -y httpd",
      "sudo systemctl start httpd",
      "sudo systemctl enable httpd"
    ]
  }
}

This Terraform file creates an AWS EC2 instance.

The connection block tells Terraform how to connect to the instance using SSH:

• type: specifies SSH connection.
• user: the username to log in as.
• private_key: the SSH private key file used for authentication.
• host: the IP address of the instance to connect to.

The provisioner "remote-exec" runs commands on the remote server after creation.

Commands

This command initializes the Terraform working directory. It downloads necessary provider plugins and prepares Terraform to run.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.

This command creates the AWS EC2 instance and uses the connection block to SSH into it and run the setup commands automatically.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.example: Creating...

aws_instance.example: Still creating... [10s elapsed]

aws_instance.example: Creation complete after 20s [id=i-0abcd1234efgh5678]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approves the apply without asking for confirmation

This command removes the AWS EC2 instance and cleans up all resources created by Terraform.

Terminal

terraform destroy -auto-approve

Expected Output

aws_instance.example: Destroying... [id=i-0abcd1234efgh5678]

aws_instance.example: Destruction complete after 10s



Destroy complete! Resources: 1 destroyed.

→

-auto-approve - Automatically approves the destroy without asking for confirmation

Key Concept

If you remember nothing else from this pattern, remember: connection blocks tell Terraform how to securely SSH into remote machines to run commands or copy files during provisioning.

Common Mistakes

Not specifying the correct SSH user in the connection block.

Terraform cannot log in to the remote server if the username is wrong, causing connection failures.

Use the correct username for the server, like 'ec2-user' for Amazon Linux or 'ubuntu' for Ubuntu servers.

Using the wrong path or permissions for the private key file.

Terraform fails to authenticate if the private key is missing, unreadable, or has incorrect permissions.

Ensure the private key file exists, is readable, and has secure permissions (e.g., 600). Use the full path or '~/.ssh/id_rsa'.

Not using the instance's public IP or hostname in the host field.

Terraform cannot connect if it tries to use a private IP or an undefined host.

Use 'self.public_ip' or a valid reachable IP address or DNS name for the host in the connection block.

Summary

Use a connection block in Terraform to define how to SSH into remote servers.

The connection block includes user, private key, host, and connection type.

Terraform uses this connection to run commands or copy files during provisioning.

Practice

1. What is the main purpose of a connection block in Terraform when using SSH?

easy

A. To specify the Terraform backend storage

B. To define how Terraform connects to remote machines for running commands or copying files

C. To configure the cloud provider credentials

D. To create a new SSH key pair automatically

Solution

1. Step 1: Understand the role of connection blocks

   Connection blocks specify how Terraform connects to remote machines, typically using SSH, to run commands or transfer files during provisioning.

2. Step 2: Differentiate from other configurations

   SSH key creation, cloud credentials, and backend storage are configured elsewhere, not in connection blocks.

3. Final Answer:

   To define how Terraform connects to remote machines for running commands or copying files -> Option B

4. Quick Check:

   Connection block purpose = Define SSH connection [OK]

Hint: Connection blocks set SSH details for remote commands [OK]

Common Mistakes:

• Confusing connection block with SSH key creation
• Mixing connection block with cloud provider config
• Thinking connection block manages backend storage

2. Which of the following is the correct syntax to specify an SSH connection block in Terraform?

easy

A. connection { type = "winrm" user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") }

B. connection { protocol = "ssh" username = "ubuntu" address = self.public_ip key = file("~/.ssh/id_rsa") }

C. connection { ssh_user = "ubuntu" ssh_host = self.public_ip ssh_key = file("~/.ssh/id_rsa") }

D. connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") }

Solution

1. Step 1: Recall Terraform connection block syntax

   The correct keys are user, host, and private_key. The type key is not required for SSH as it is the default.

2. Step 2: Identify the valid syntax

   connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") } uses correct keys without unnecessary or incorrect ones like type or protocol.

3. Final Answer:

   connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") } -> Option D

4. Quick Check:

   Correct keys = user, host, private_key [OK]

Hint: Use user, host, private_key keys in connection block [OK]

Common Mistakes:

• Adding unnecessary 'type' or 'protocol' keys
• Using wrong key names like ssh_user or username
• Omitting required keys like user or host

3. Given this Terraform snippet, what will happen when Terraform tries to connect?

connection {
  user = "admin"
  host = aws_instance.example.public_ip
  private_key = file("~/.ssh/id_rsa")
  timeout = "2m"
}

medium

A. Terraform will connect but ignore the timeout setting

B. Terraform will fail because timeout must be a number, not a string

C. Terraform will connect using SSH as user 'admin' with a 2-minute timeout

D. Terraform will connect using default user instead of 'admin'

Solution

1. Step 1: Analyze connection block fields

   The block correctly sets user, host, private_key, and timeout. Timeout accepts a duration string like "2m".

2. Step 2: Understand Terraform SSH connection behavior

   Terraform uses these values to connect via SSH as user 'admin' with a 2-minute timeout for connection attempts.

3. Final Answer:

   Terraform will connect using SSH as user 'admin' with a 2-minute timeout -> Option C

4. Quick Check:

   Timeout string '2m' is valid duration [OK]

Hint: Timeout accepts duration strings like '2m' for SSH connections [OK]

Common Mistakes:

• Thinking timeout must be numeric only
• Assuming default user is used ignoring 'user' key
• Believing timeout is ignored by Terraform

4. Identify the error in this Terraform connection block:

connection {
  user = "ec2-user"
  host = aws_instance.web.public_ip
  private_key = "~/.ssh/id_rsa"
}

medium

A. private_key should use file() function to read the key content

B. host should be a static IP, not a resource attribute

C. user must be 'ubuntu' for AWS instances

D. Missing 'type = "ssh"' in connection block

Solution

1. Step 1: Check private_key value type

   The private_key must contain the actual key content, not just the file path string. Using file("~/.ssh/id_rsa") reads the key content.

2. Step 2: Validate other fields

   Host can be a resource attribute, user can be 'ec2-user' for Amazon Linux, and 'type' defaults to SSH so it's optional.

3. Final Answer:

   private_key should use file() function to read the key content -> Option A

4. Quick Check:

   private_key needs file() to read key [OK]

Hint: Use file() to load private_key content, not just path string [OK]

Common Mistakes:

• Assigning private_key a file path string directly
• Assuming host cannot be a resource attribute
• Forcing user to 'ubuntu' regardless of OS

5. You want to run a remote command on an AWS instance using Terraform. Which connection block setup is best practice to ensure a reliable SSH connection?

hard

A. connection {
user = "ec2-user"
host = aws_instance.app.public_ip
private_key = file("~/.ssh/id_rsa")
timeout = "5m"
agent = true
}

B. connection {
user = "ec2-user"
host = aws_instance.app.public_ip
private_key = file("~/.ssh/id_rsa")
timeout = "1m"
agent = false
}

C. connection {
user = "ec2-user"
host = aws_instance.app.private_ip
private_key = file("~/.ssh/id_rsa")
timeout = "5m"
agent = true
}

D. connection {
user = "ubuntu"
host = aws_instance.app.public_ip
private_key = file("~/.ssh/id_rsa")
timeout = "30s"
agent = false
}

Solution

1. Step 1: Choose correct user and host

   For AWS Amazon Linux, user is usually 'ec2-user'. Public IP is needed for SSH from outside the VPC.

2. Step 2: Set appropriate timeout and agent

   A longer timeout like "5m" helps with slow connections. Using SSH agent forwarding (agent = true) can improve key management.

3. Step 3: Compare options

   connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true } uses correct user, public IP, sufficient timeout, and enables agent forwarding, matching best practices.

4. Final Answer:

   connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true } -> Option A

5. Quick Check:

   Public IP, correct user, timeout 5m, agent true = best practice [OK]

Hint: Use public IP, correct user, 5m timeout, and agent true for reliability [OK]

Common Mistakes:

• Using private IP when public IP is needed
• Setting too short timeout causing failures
• Disabling agent forwarding unnecessarily
• Using wrong user for the OS