This bug was fixed in the package cloud-init - 20.4-0ubuntu1~20.04.2 --------------- cloud-init (20.4-0ubuntu1~20.04.2) focal; urgency=medium
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys (#760) (LP: #1910835) -- Chad Smith <chad.sm...@canonical.com> Mon, 11 Jan 2021 15:25:31 -0700 ** Changed in: cloud-init (Ubuntu Focal) Status: Fix Committed => Fix Released ** Changed in: cloud-init (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1910835 Title: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Bionic: Fix Released Status in cloud-init source package in Focal: Fix Released Status in cloud-init source package in Groovy: Fix Released Status in cloud-init source package in Hirsute: Fix Released 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://github.com/canonical/cloud- init/blob/master/tests/integration_tests/bugs/test_lp1910835.py). 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_keys preventing ssh access for cloud-generated keys. 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_keys. 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_data.imds.compute.publicKeys}}' [{'keyData': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU= generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}] cloud-init renders this directly to .ssh/authorized_keys without processing the string, resulting in an invalid keyline: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M 9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M 4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M 6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M iKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht^M 6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9^M S2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU= generated-by-azure this prevents ssh from actually reading the right key from azure: $ ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys If we strip the CRLF (^M) characters and reparse with ssh-keygenm we see the proper key registered: $ ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys 3072 SHA256:PQ9EKxTKONJKFC2N56UpL6+Oc/cujfA9HpsF5VW2QDI generated-by-azure (RSA) If cloud-init (or IMDS) were to strip those \r\n characters from each line ssh To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910835/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp