Allow generation of other types of SSH CA keys

[cipherboy]

Curious about general sentiment here; if it is positive, I'll add docs and a changelog and we can decide what to do about the UI (leave it as-is or drop it for future work).

See #11035 for context. We derive types from the x/crypto/ssh types (which match OpenSSH's constants), thus making key bits only relevant for RSA keys. We're notably short exporting the private key (for parity with PKI secrets engine).

Resolves: #11035

---

This probably needs some additional UI work, but it works 😆

@ivana-mcconnell or @hellobontempo do either you have any thoughts here? It seems like the UI of SSH CA generation isn't at all like the PKI functionality; it looks like there's no dynamic fields (the hbs template needed to be updated manually) and lacks a lot of the actions for groups or changes &c. I couldn't figure out how to use a <Select /> component either; it appears to require an onChange action (which we appear to lack completely) and even without it, the options didn't populate (either manually or from the element's chosen values). Similarly failed via <FormFieldFromModel /> -- that didn't even display at all. :/

Edit: Screenshot

[stevendpclark]

Overall +1 from me, a few little nits on the specific PR and I'll let others discuss/decide about the UI parts of this PR, hence the lack of approval from my part.

[sgmiller]

Looks good to me. Needs docs and changelog though.

[ivana-mcconnell]

@cipherboy Thanks! Just wanting to make sure I understand the desired behaviour here: we want to enable a user to select the key type first (from ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, or ssh-ed25519) and then, based on that, enter the key bits. Is that correct?

Should key bits be an open input, or are there only specific values that are allowed for each key type?

[cipherboy]

Hey @ivana-mcconnell!

I'd actually love to see something similar to those boxes in the PKI UI RFC doc where the user first selects if they're going to import a SSH CA (first two fields on that form) OR if they're going to generate a key. (Or put them under folding menus, you'd know better than me!).

In the former case, they just need the top two fields (private/public key).

In the latter case, they just need the two new fields. Yes, ideally a drop-down would be best for the key type; I tried getting that working with a select but failed. Presently key bits is only necessary when keyType == ssh-rsa so yes, could definitely be hidden otherwise :-) For now, its the standard RSA key sizes (which would either be an int or if you wanted some sane limits, values of 2048, 3072, 4096, and maybe something larger but unlikely). Lemme know if you think there's some easy fixes I could do (and some existing code that does it right) or what :-)

[hellobontempo]

Hey @ivana-mcconnell!

I'd actually love to see something similar to those boxes in the PKI UI RFC doc where the user first selects if they're going to import a SSH CA (first two fields on that form) OR if they're going to generate a key. (Or put them under folding menus, you'd know better than me!).

In the former case, they just need the top two fields (private/public key).

In the latter case, they just need the two new fields. Yes, ideally a drop-down would be best for the key type; I tried getting that working with a select but failed. Presently key bits is only necessary when keyType == ssh-rsa so yes, could definitely be hidden otherwise :-) For now, its the standard RSA key sizes (which would either be an int or if you wanted some sane limits, values of 2048, 3072, 4096, and maybe something larger but unlikely). Lemme know if you think there's some easy fixes I could do (and some existing code that does it right) or what :-)

Once design (@ivana-mcconnell) has put together designs for this I'm happy to review your PR, or pair through implementing in the UI

[cipherboy]

fmt errors all in unrelated files.

Per discussion with @ivana-mcconnell, removed the fledgling UI :-)