Open ubuntu-server-builder opened 1 year ago
Launchpad user Ryan Harper(raharper) wrote on 2020-03-27T14:52:02.425053+00:00
Related background, https://bugs.launchpad.net/ubuntu/+source/ec2-init/+bug/458576
This is currently expected behavior. Cloud-init's write-ssh-key-fingerprints[1] helper is called by cloud-init in the final stage. The helper logged these values setting the program name to 'ec2'. This was a compatibility change made for OpenStack and other Ec2 look-alikes.
When ec2-init was renamed to cloud-init this string was not updated. I'm leaning toward replacing 'ec2' with 'cloud-init'.
Launchpad user Scott Moser(smoser) wrote on 2020-03-29T03:18:59.347921+00:00
fwiw, changing this may well break things.
Anything that is reading the output of a log in order to get ssh keys would be expecting lines to start with ec2. So...while that unfortunately isn't 'cloud-init' or 'azure', it is what users expect.
I'd leave it as it is. The keys are written in a more machine friendly way also. See bug 893400
Launchpad user Dan Watkins(oddbloke) wrote on 2020-03-30T14:31:47+00:00
On Sun, Mar 29, 2020 at 03:18:59AM -0000, Scott Moser wrote:
fwiw, changing this may well break things.
Anything that is reading the output of a log in order to get ssh keys would be expecting lines to start with ec2. So...while that unfortunately isn't 'cloud-init' or 'azure', it is what users expect.
This doesn't seem like a major change for users to have to handle. I agree that we shouldn't introduce it into existing Ubuntu releases, but from an upstream cloud-init POV, I don't see why we wouldn't fix it for future releases.
I'd leave it as it is. The keys are written in a more machine friendly way also. See bug 893400
Given that there is a better way available (and has been for long enough that it should be available ~everywhere), would a more appropriate path forward be to deprecate and/or remove this output, instead of fixing it up?
Launchpad user Scott Moser(smoser) wrote on 2020-03-30T15:50:25.963678+00:00
Given that there is a better way available (and has been for long enough that it should be available ~everywhere), would a more appropriate path forward be to deprecate and/or remove this output, instead of fixing it up?
I'd say your two options are: a.) ignore the fact that this says 'ec2'. There are literally thousands of lines of output on a linux console. Don't fret over one of them listing a platform other than your own. b.) drop it entirely.
option 'c' would be to change it to say "azure" when it is on azure. That doesn't seem like it would help anyone, but only make it seem like someone should pay attention to it.
Launchpad user Dan Watkins(oddbloke) wrote on 2020-03-30T16:15:48+00:00
On Mon, Mar 30, 2020 at 03:50:25PM -0000, Scott Moser wrote:
Given that there is a better way available (and has been for long enough that it should be available ~everywhere), would a more appropriate path forward be to deprecate and/or remove this output, instead of fixing it up?
I'd say your two options are: a.) ignore the fact that this says 'ec2'. There are literally thousands of lines of output on a linux console. Don't fret over one of them listing a platform other than your own.
I think calling this "fret"ting is unfair. This is inconsistent behaviour (nothing else in cloud-init logs as "ec2"), and it's reasonable to wonder if something claiming to be "ec2" on the console should be running on non-EC2 platforms.
b.) drop it entirely.
option 'c' would be to change it to say "azure" when it is on azure. That doesn't seem like it would help anyone, but only make it seem like someone should pay attention to it.
I think if we were to change it to anything, it would be to a platform-agnostic "cloud-init" (which would also be consistent with the rest of cloud-init's logging). The fact that this is "ec2" currently is a historical artifact, not an intentional choice to use a platform name.
Launchpad user Johnson Shi(johnsonshi) wrote on 2020-04-06T23:03:58.420354+00:00
Hey just chiming in my thoughts =). I think this isn't just about Azure VMs, but also about other clouds like GCE and other clouds. It certainly won't be a good user experience for non-EC2 customers to see ec2 in their output.
Launchpad user Johnson Shi(johnsonshi) wrote on 2020-04-06T23:05:42.707963+00:00
I agree with Dan's suggestion that this needs to be changed to a platform-agnostic log output so that users of non-EC2 cloud will have a consistent user experience. Having non-EC2 customers see EC2 related output, especially regarding host keys, would raise a lot of eyebrows.
Launchpad user Dan Watkins(oddbloke) wrote on 2020-04-07T21:30:00.180373+00:00
The keys are written in a more machine friendly way also.
I'm looking at (a focal lxd) console, and the two ways I see the host keys written are (each of which is repeated per key type):
Apr 07 20:23:54 unique-filly cloud-init[320]: Generating public/private dsa key pair. Apr 07 20:23:54 unique-filly cloud-init[320]: Your identification has been saved in /etc/ssh/ssh_host_dsa_key Apr 07 20:23:54 unique-filly cloud-init[320]: Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub Apr 07 20:23:54 unique-filly cloud-init[320]: The key fingerprint is: Apr 07 20:23:54 unique-filly cloud-init[320]: SHA256:lCiVjNhfVGOMNEHdXwI3Cx+ljhI+LwuXBxHaGayVHQA root@unique-filly
which is repeated per key type, and the output being discussed here:
Apr 07 20:24:09 unique-filly ec2[1215]: 1024 SHA256:lCiVjNhfVGOMNEHdXwI3Cx+ljhI+LwuXBxHaGayVHQA root@unique-filly (DSA)
To my eyes, the latter output is much more machine friendly, because it's all contained in a single line.
Am I missing another way of getting the host keys emitted to the console? (Perhaps you were thinking of cc_ssh_authkey_fingerprints, which is for authorised keys?)
This bug was originally filed in Launchpad as LP: #1869277
Launchpad details
Launchpad user Johnson Shi(johnsonshi) wrote on 2020-03-27T00:21:28.514419+00:00
The write-ssh-key-fingerprints writes to console as 'ec2' when it should use 'cloud-init'
-- original description --- Azure VMs that are deployed sometimes show EC2 related output. This happens intermittently.
Output of bug find is here: https://paste.ubuntu.com/p/nrWNYjzsXH/