sshPublicKeys module

[Grant-Rc]

Hello guys,

Would it be possible to have a module for the creation of 'sshPublicKeys' resource if not exist?

Deploying a VM for the team using the module virtualMachines and found that they need a new sshkey created. Ideally this would be all self-contained rather than creating the ssh key in a different pipeline.

resource symbolicname 'Microsoft.Compute/sshPublicKeys@2022-11-01' = if (empty(publicKeys)) { name: 'string' location: location tags: { tagName1: 'tagValue1' tagName2: 'tagValue2' } }

This will create the SSH pair and then we can pass the details up to the Microsoft.Compute/virtualMachines deployment. The extra steep would be where the private key gets stored, and I assume that could be solved by storing it in a keyvault.

Im going to try and put this together now if you would like to see the end resault?

[Grant-Rc]

or am i going about this all wrong? should i be just creating a new key directly in keyvault? and then pulling the public key from it?

[eriqua]

@Grant-Rc, thanks for opening this discussion and sorry for the late reply. Discussions are currently not monitored promptly and are planned to be disabled in favor of the new issue template [Questions/Feedback].

That said, regarding your inquiry, we recently merged the sshPublicKeys module through PR #2673.
Please have a look and let us know if that helps. Please note that the module does not generate a key pair itself. We're planning to revisit the way public keys are generated in our test files and to provide a construct serving as an example of module usage for cases similar to the one you're referring to. You can refer to issues #3118 and #3119 for further details.

[eriqua]

Hi @Grant-Rc, thanks again for opening this discussion.

CARML evolved to and has been rebranded as the Bicep version of Azure Verified Modules (AVM)).

All modules previously hosted by this repo have been updated to align with AVM specifications and published to the Public Bicep Registry. Their evolved source code can be found in the underlying repository (BRM)

However, in order not to lose relevant discussions like this one, all CARML GitHub discussions are being converted to CARML GitHub issues, in order for the team to be able to further triage them and migrate them to AVM issues, if applicable.

Please refer to issue #4544 going forward.