← Back to team overview

cloud-init team mailing list archive

Re: cloud-init - questions as I read


On 09/01/2017 19:34, Scott Moser wrote:
On Wed, 21 Dec 2016, Michael Felt wrote:

I am working through cloud-init and shall pose questions as I go. I am hoping
for enlightenment from any/all of you.

Had a discussion about the /etc/cloud/cloud.cfg contents - just these two
lines for now:

Currently they are:

# Delete existing SSH host keys
ssh_deletekeys: true

# Regen rsa and dsa host keys
ssh_genkeytypes: ['rsa', 'dsa']

IMHO - they should be: (because "straight dsa" is considered too "weak")

# Delete existing SSH host keys
ssh_deletekeys: true

# Regen rsa and dsa host keys
ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519']
Thats a reasonable suggestion.

I have been told that ssh_deletekeys: true
ONLY deletes the keys that are included in the "genkeytypes" list. certainly
not what I expected from a "instance initialization machine". I was expecting
it to delete all keys, regardless - in other words, by default: true means
delete all from the default location.
Well, the code does this:
     # remove the static keys from the pristine image
     if cfg.get("ssh_deletekeys", True):
         key_pth = os.path.join("/etc/ssh/", "ssh_host_*key*")
         for f in glob.glob(key_pth):
             except Exception:
                 util.logexc(log, "Failed deleting key file %s", f)

so effectively if /etc/ssh is the right path, then setting it to 'True'
does what you want. So i'm perfectly happy to allow that to mean:
   "Delete any found generated host keys in the system".
This is what I thought/expected it to mean - delete all keys, so imho the behavior to delete all keys from "somewhere" is fine. Hence - a lot of the "extra" below is unneeded. That was based on the idea that what I had been told - namely, not all keys were deleted. The only real point remaining is to permit searching more than one directory, rather than only one - AND/OR be able to specify a different directory.
What I see as a useability feature is an option to say something like: (I do
not know json yet, so PLEASE, pick away - fix it!)

ssh_deletekeys: true: { true, [path1, path2]} or

ssh_deletekeys: true: {["key1", "key2"], ["path1", ..., "pathN"]}

Again, the default, imho, should be, if true, to delete all keys from (all)
default path(s)
I think we can punt on a more complex value than a boolean as the 'True'
does what you think it should, alhtough only for keys in /etc/ssh... i see
that as a bug in the implementation.
You would/do see multiple directories for ssh keys as a bug? Or something else. Your comment is not clear to me.
The ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519'] would be very similiar -
except we have no need for an additional 'true' - calling it implies 'true'.
However, to make a path "override" easy to see and do have the call ALSO

ssh_genkeytypes: { ['rsa', 'ecdsa', 'ed25519'], ["path1", ..., "pathN"]}
One thing to note is that we are generally moving to namespacing
configuration under a top level key.  Ie, many config modules are moving
   ssh_genkeytypes: ..
   ssh_deletekeys: true

to the more sane and extensible:

     genkeytypes: ...
     deletekeys: true

And then generally, I prefer to use dictionaries over lists, so:
       path: /etc/ssh/ssh_host_key_rsa
       type: rsa
       path: /etc/ssh/ssh_host_key_rsa
       type: ecdsa

Above, the key name ('rsa' or 'ecdsa') would largely be ignored, but we
could have the type default to the key name if not provided.
Apart from the typo (key_rsa twice): my experience with packaging openssh implies that the keys looked at by sshd are in one directory. Probably those can be specified on a per-directory basis (would have to check).

So, lets assume it is just one path:

    path: /etc/ssh
    name: ssh_host_$type_key
    comment: "cloud-init generated ssh_key on $date"
    bits: 4096
      bits: 2048
      name: ssh_host_rsa_key # Actually same as default
      comment: "A comment string that overrides the 'default' above"
    ecdsa: defaults
    ed25519: defaults

But that is much more verbose for someone wanting to modify config or
change it.

So, in summary

a) is current behavior to only delete the keys selected for generation - other
keys, if any, are not deleted.
:) Happy me!
b) change default behavior for delete to ALL in (ALL) default location(s)
Sounds like the original intent for 'true'.

c) add a way to specify both specific keys and/or (additional) paths to both
I agree with generate for sure, i'm not convinced that a boolean for
delete doesnt suffice, with code that "does the right thing" (deleting
them from whatever directory they'd likely be in).

Footnote: As mentioned above - I port OSS to AIX. And one of the dangers of OSS is breaking a working situation aka I do not believe I have the 'right' to overwrite system files - this is the whole point of why "/usr/local" originated 40 years ago. I assume I am a "minority of one", but I have learned the hard way that changes to ssh/sshd can break things (many many clients are ancient - I only recently found my last "dsa" key I was still using.)

** I just re-read the LHS document - and being 'smarter now' I see some things I will need to think about making some changes to how I select certain directories. In LHS they distinguish between "shareable" aka "not host/machine bound", and "unshareable" aka "host/machine" bound. AIX has three categories: "root" is the LHS concept of "unshareable". For the "shared" category, AIX has two labels: "USR" (originally for /usr only, it now include /opt as well). These are meant to be "static" (in the LHS sense) and shareable with any other AIX system at the same OS level (not not shareable between AIX 6.1 TL8 and AIX 6.1 TL9) - and the third category is "share": these files follow the "Linux" shared in that they are meant to be shareable over any version of AIX or UNIX (or Linux). Man pages, terminal definitions (e.g. curses) are examples.

To get to a close: Every distribution will have slight differences - and I would like to continue to think about a manageable way to specify what has a default, and how to modify a default.

As far as "/etc/ssh" is concerned (as a path) - I have a vested interest in it being able to be something else. Feel free to ignore me in this specific case. However, I do hope you are at least thinking about other cases (that you know of) with different packages, device names, etc..

Sigh :p@me

Follow ups