write-ssh-key-fingerprints writes to console as 'ec2'

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'.

1. https://github.com/canonical/cloud-init/blob/master/tools/write-ssh-key-fingerprints#L4

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

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?

> 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.

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.

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.

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.

> 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?)

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3636