ssh public key forces replacement "azurerm_linux_virtual_machine"

[ghost]

This issue was originally opened by @jorchis05 as hashicorp/terraform#26862. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Good morning,

We have an infrastructure generated in Azure which we are terraforming with the Terraformer tool.

Once we have the infrastructure code we are having problems with the resource "azurerm_linux_virtual_machine" and with the admin_ssh_key "public_key".
Our virtual machine has a linked ssh key. Which we reference through a .pub file and with the following code:

admin_ssh_key {
username = "dam"
public_key = file("~/.ssh/public_key.pub")
}

After performing the command terraform plan we realize that it tries to replace the public_key because the information that Terraform collects from the public key is in heredoc format with carriage returns and our .pub file does not have them.
Attached is a screenshot of the terraform plan.

Could you help us with this case?

Versions:
Terraform v0.12.29
Provider azurerm: 2.20.0
Terraformer: v0.8.9

Thank you very much.

Regards.

[DenWin]

Hi,
Terraform compares - as far as I know even case sensitive. Therefore the only option would be to change your .pub file into heredoc format.

Regards

[jorchis05]

Hi,
Terraform compares - as far as I know even case sensitive. Therefore the only option would be to change your .pub file into heredoc format.

Regards

Hi @DenWin ,

When I modify the .pub file to heredoc format, I lose the public key format.

How can i change the format of the .pub file to heredoc format?

Thank you very much for the answer.

Regards

[DenWin]

do you need this file anywhere else?
If not reshape it to match, what Terraform expects.
You could e.g. copy paste, what Terraform claims it has to match (keep the end of line-characters in mind - most probably Linux style).

Also I'm not that familiar with that, but I'm rather sure that a public key is valid no matter how it is broken over into the next line, hence the here-doc version is as valid as the single line version. Even a completely odd broken here-doc version should still work - well not in Terraform where a character comparison takes place.

[AleFazio]

do you need this file anywhere else?
If not reshape it to match, what Terraform expects.
You could e.g. copy paste, what Terraform claims it has to match (keep the end of line-characters in mind - most probably Linux style).

Also I'm not that familiar with that, but I'm rather sure that a public key is valid no matter how it is broken over into the next line, hence the here-doc version is as valid as the single line version. Even a completely odd broken here-doc version should still work - well not in Terraform where a character comparison takes place.

Hi, @DenWin
I have the same issue. I tried heredoc syntax by using the ssh key in single line but Terraform still tries to replace the resource and that’s not possible for our project.
I also tried using multiline version by copy-pasting the key from the plan output but Terraform raises the following error: “Error parsing "admin_ssh_key.0.public_key" as a public key object”.

In multiline version, I tried with and without \r\n characters (included in the key as it displays in the terraform state file) but the error is still the same with heredoc syntax.
If I use multiline string, Terraform doesn’t accept it and the following message will prompt:
Quoted strings may not be split over multiple lines. To produce a multi-line
string, either use the \n escape to represent a newline character or use the
"heredoc" multi-line template syntax.

But if I use \n or \r\n Terraform raises parsing error.
Can you suggest me ho to handle this? Could it be an indentation problem?

Thanks in advance

[jackofallops]

Hi @jorchis05 / @DenWin
I'm investigating this issue at the moment and I'm not able to reproduce it. Can you give me some information on how the the VM and the KeyPair was created? (e.g. was it via the portal and imported?)

[DenWin]

@jackofallops : I'm out here, just tried to give additional advice without knowledge about actual issue at hand.

[AleFazio]

Hi @jorchis05 / @DenWin
I'm investigating this issue at the moment and I'm not able to reproduce it. Can you give me some information on how the the VM and the KeyPair was created? (e.g. was it via the portal and imported?)

The keyPair, in my case, was created through the Portal (you can see "generated by azure" at the end of the key) along with the VM.
The issue also occurs with key of the type
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20200715"
ssh-rsa AAA....
---- END SSH2 PUBLIC KEY ----
while it doesn't if the key has been copy/pasted as simple string type, during VM creation: "ssh-rsa AAA....".
The problem is probably related to the Windows format (not Unix) of the key itself that is not accepted by Terraform but we can't replace the key only in the VM without destroying the VM itself.

[frontegi]

Hi @jackofallops , to reproduce you can:

• create a Linux VM in Azure, and make the SSH key auto-generated by the portal ("SSH Public Key Source"= "Generate New Key Pair")
  Note: The key is stored inside the VM in the .ssh folder without newlines. If you export the ARM template from Azure, the key is stored on multiple lines, with newlines ("\r\n").
• import the resource in .tfstate using "terraform import azurerm_linux_virtual_machine.linux-vm <resource_id>"
• setup accordingly the resource in the .tf, with the corresponding admin_ssh_key.public_key . It doesn't care if on multiple lines (hereDoc), single line or imported from file (es: file("~/.ssh/auto_generated_rsa.pub") )
• execute terraform plan .
• change is detected

If you try to write the keys in different ways ("with \r\n, \r, on multiple line, changing the encoding and so on") you always fall inside one of the validation branch present in the function:
https://github.com/terraform-providers/terraform-provider-azurerm/blob/0758991b63e628379c88f2d599c1cf5c51d5447f/azurerm/internal/services/compute/ssh_keys.go#L119

if you format the string to pass the validation (single line), the difference is detected, due to the \r\n retrieved by the provider that are not recognized by the local tf code representation.

If you reset the SSH key in the portal, the new key is appended to the existing one in the machine.
So the provider continue to read the first ssh key falling again and again in the issue.

[jackofallops]

Thanks @frontegi - I'll continue to look into this.

[frontegi]

Thanks @jackofallops for the effort in solving this issue.

[AleFazio]

Thanks @jackofallops for the help!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!