cloud-init team mailing list archive

[Michael Felt <michael@xxxxxxxxxxxxx>]

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):
>              try:
>                  util.del_file(f)
>              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
> > support:
> >
> > 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
> from:
>    ssh_genkeytypes: ..
>    ssh_deletekeys: true
>
> to the more sane and extensible:
>
>    ssh:
>      genkeytypes: ...
>      deletekeys: true
>
> And then generally, I prefer to use dictionaries over lists, so:
> ssh:
>    genkeytypes:
>      rsa:
>        path: /etc/ssh/ssh_host_key_rsa
>        type: rsa
>      ecdsa:
>        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:

ssh:
  defaults:
    path: /etc/ssh
    name: ssh_host_$type_key
    comment: "cloud-init generated ssh_key on $date"
    bits: 4096
  genkeytypes:
    rsa:
      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.
> No.
:) 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
> > "calls"
> 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