When playing around with Microsoft Azure CLI you will stumble on something called Cloud-init to inject custom data into the newly created Linux VM.
Within the Az CLI 2.0 there is a parameter –custom-data that takes a yaml like input file with Cloud-init configuration that is supposed to be rolled out on the host.
However, this collides with the parameter –admin-user. Let me explain:
You create a Linux host without custom data:
$ az vm create \ --resource-group <groupname> \ --name <hostname> \ --admin-username 'azureuser' \ --generate-ssh-keys \ --image UbuntuLTS
The snippet above will create a host with a local user azureuser and place the local public key
host:/home/azureuser/.ssh/authorized_keys if the key exists. If
~/.ssh/id_rsa does not exist, it will be created and then deployed.
Now the custom data comes into play: By creating a cloud-init file, one of the options is to create one or multiple local users on the host.
$ cat cloud-init.txt #cloud-init users: - name: testuser $ az vm create \ --resource-group <groupname> \ --name <hostname> \ --admin-username 'azureuser' \ --generate-ssh-keys \ --image UbuntuLTS \ --custom-data cloud-init.txt
Using this setup will lock you out of the machine. Why? Well:
- The local user testuser is created on the host.
- The local user azureuser is not(!) create on the host.
- Since neither password nor SSH key are defined for the local user, you don’t have access.
In other words: defining any number of users in a custom configuration will render the parameter –admin-user ineffective.
The deployment logs show, that the custom ssh key is supposed to be used during the deployment, but it is not and does not show up on the created machine.
[...] Use existing SSH public key file: /home/<user>/.ssh/id_rsa.pub [...]
To gain access again, you have to at least specify a password hash or a public key file in your custom cloud-init:
$ cat cloud-init.txt #cloud-init users: - name: testuser ssh-authorized-keys: - ssh-rsa ASID/<snip>