The ~ in path are treated as usual character

[eugenydavydov]

Terraform Version

Terraform v0.14.7

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

Affected Resource(s)

local_file

Terraform Configuration Files

resource "local_file" "ssh_key_private" {
  filename             = "~/.ssh/${local.env}.pem"
  directory_permission = 0755
  file_permission      = 0400
  sensitive_content    = data.aws_ssm_parameter.ssh_private_key.value
}

Expected Behavior

/home/${username}/.ssh/${local.env}.pem created.

Actual Behavior

/home/${username}/current_path/~/.ssh/${local.env}.pem created.

Steps to Reproduce

1. terraform apply

[sobi3ch]

I think you should use pathexpand("~/.ssh/id_rsa") buildin fucntion, which expand to /home/username/.ssh/id_rsa
Docs: https://www.terraform.io/docs/language/functions/pathexpand.html

[apparentlymart]

Indeed, this ~ convention is normally handled by a Unix-style shell rather than individual applications, and so usually Terraform and providers don't support it except for unusual cases where the given path is used to build a command run through a shell.

The pathexpand function suggested by @sobi3ch is there to deal with situations where you'd like to have a shell-like expansion for a path that won't pass through a Unix-style shell. It's not 100% compatible with how shells behave, but it's close enough for simple situations like this one.

---

Please note the warning in the function's documentation:

Using this function in resource arguments will cause spurious diffs if the same configuration is run by multiple users with different home directory paths, or used on different host operating systems. We recommend using this function only for transient values, such as in connection and provisioner blocks to locate SSH keys, etc.

That means that if your home directory on your current computer is /home/example1 then the expanded path would be /home/example/.ssh/envname.pem, and that absolute path will be recorded in the Terraform state as the prior state of this resource instance. If one of your colleagues then applies this on their own computer where their home directory is /home/example2, they will see Terraform report that the filename is changing from yours to theirs:

  ~ filename = "/home/example1/.ssh/envname.pem" -> "/home/example2/.ssh/envname.pem"

For this particular application I don't think this matters very much, since the file will ultimately still get written in the intended location during the apply phase. It just might seem a little confusing when reviewing the plan diff, so probably best to document this as part of your system to avoid any concerns by your colleagues who are not familiar with this quirk.