Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Critical
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Groovy |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys provided by the Azure platform. cloud-init 20.4 replaced that code with a more efficient implementation, but one which did not use OpenSSL: this meant that users passing certificates to instances, or users generating SSH keys in Azure's web UI (which inserts \r\n sequences into the public key content), were regressed: their certificates and malformed SSH keys were no longer handled, so they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely affects Azure platform. It is a critical bug we wish to release as soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception which forces cloud-init to revert to previous released logic of the previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need not apply. An upstream integration test has been written for this issue (https:/
A full run of the upstream test suite on Azure will therefore regression test the update generally and test this issue specifically: a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure, specifically to revert to a previous behaviour: users unaffected by the bug should see no change (their keys will get to their instance via a different route), and users affected by the bug would have been unable to access their instances before (so cannot be relying on this behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to --generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to .ssh/authorized
To reproduce: launch an ubuntu VM from the portal.azure.com choosing to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content provided in the metadata publicKeys value contains CRLF characters (\r\n) thus splitting the content of the pubkey onto multiple lines when it is rendered into .ssh/authorized
the solution is either for IMDS to stop adding the CRLF characters or cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_
[{'keyData': 'ssh-rsa AAAAB3NzaC1yc2E
cloud-init renders this directly to .ssh/authorized
ssh-rsa AAAAB3NzaC1yc2E
9FqyYOu0xxHmpXT
lkINfuPVBDfRtSf
4jAXmydwtNCN2iG
6xxCkQcdCLospgq
iKqKJMvYVhil3kh
6eERfxMBNg3udv1
S2mLJ6Peu/
this prevents ssh from actually reading the right key from azure:
$ ssh-keygen -lf /home/ubuntu/
If we strip the CRLF (^M) characters and reparse with ssh-keygenm we see the proper key registered:
$ ssh-keygen -lf /home/ubuntu/
3072 SHA256:
If cloud-init (or IMDS) were to strip those \r\n characters from each line ssh
summary: |
- Auzre IMDS publicKeys contain \r\n which prevents ssh access to vms + Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. |
description: | updated |
description: | updated |
description: | updated |
Changed in cloud-init (Ubuntu Hirsute): | |
status: | New → Fix Released |
Changed in cloud-init: | |
status: | Confirmed → Fix Released |
To work around this issue in cloud-init 20.4 on azure, one can launch a VM providing cloud-config userdata which contains the unsplit pubkey content.
userdata can be added in the Advanced tab in Azure portal dashboard or on the az cli via the cmdline parameters --custom-data mycloudconfig.yaml
For the auto-generated key listed in the above bug description the following would be the "right" #cloud-config to provide at VM launch time
#cloud-config keys: AAAADAQABAAABgQ CllNnyHXFWlMb9E KD9LZrOxt1dk/ QxYwQ0HYEP8n6TU WoUsN3mv/ Qk/qWH76Pa6f33h efzTFRiom7Ls/ tJMcr/ki8R9FqyY Ou0xxHmpXTUWFoZ QCZtGRMtvDl/ s76Wr1sCsE/ ez+EcAPeGGm/ B7jHtDAUWlkINfu PVBDfRtSfmnlCKS +sIf1XOqvRASGWi 05zAW921T4Okiat tyXyhaOimJOwq4j AXmydwtNCN2iGGK WS8YeXbtgveReqZ VVKtcDKevgWdNyq Za69uq9tRujobjC h76xxCkQcdCLosp gqX79GBbdRys6mV xVgc349RIWjQwgl RQpJwNzkeOG5Q+ La2MEhuiKqKJMvY Vhil3khzMuZwzmT rGbRx0E8AS+ Cm064RBgbcdjCW8 dDYGLuk2eQ2v9Ht 6eERfxMBNg3udv1 jmiKpjjHIg99HDU 4VqhL3aHmg+ TSrxByd0cAgFBV+ H0CiUVC9S2mLJ6P eu/HDwd88E8Wqiv 3eAsjcaCRH3QiQV aU=
ssh_authorized_
- ssh-rsa AAAAB3NzaC1yc2E