Mention/link to docs about SSH keys on instance create form

[david-crespo]

TL;DR: this is not very high priority because the upshot of the below discussion is that things are already working basically the way they're going to work. The biggest improvement we can make to the create instance form is informing the user that if they have SSH keys, they will be set on the instance they are creating, and no other keys will be (by default).

On top of that basic improvement, we could make it easy to pop open a modal to add keys if they don't already have any, or we could avoid that by linking to the SSH keys page and telling them to do it there. Of course, if they've already filled out the whole form, it would be annoying to leave and lose their progress.

---

Had a good discussion in the control plane channel about how SSH keys work on instances. Some excerpts:

Ben: Right now, it's just the SSH key for the user that creates the machine.

dap: I've assumed (maybe wrongly) that most people are going to want to manage ssh keys in some other way, and this is really for bootstrapping, demo'ing, or playing around

iliana: today, every tool that works with AWS has to assume that there is zero or one SSH key associated with a launched instance

This question came up yesterday at the product eng team sync while we were discussing the old Figma used for customer demos, which had an SSH field right on the instance create form.

As Dave pointed out, this is not really a core feature for everyday use, but rather more for getting started and doing demos. Most of the time we would expect the current user to already have a key configured, in which case they would not be adding one — we would show it and say "FYI you have an SSH key and it will be set on the machine unless you say otherwise". Or as Iliana put it:

iliana: "you have SSH keys configured; these will be the only ones on the instance and you have to add other SSH keys through some other means" is not a good sentence but is more or less what we'll need to communicate

The long term vision would be to manage SSH keys in a more elaborate way, checking if a given user has access to the instance at login time and syncing their SSH keys to the machine at that time:

rm: the longer term goal was to leverage the authorized keys plugin to reach back over metadata and ask if authorized so we didn't get into both the stomping/fighting and security issues that gcp had with their push based approach

However most enterprise customers are probably doing this themselves already and it is reasonable for them to continue to do so.

iliana: a lot of people currently using the cloud are going to be used to the current model of booting linux machines, which is that you optionally have an SSH key for bootstrapping the instance and then you set something else up during that bootstrapping
or you make your own image which already has your user management dingus set up

[just-be-dev]

I do wonder if some mechanism for choosing which SSH keys should be added to the box would be something we'd want. You could ostensibly have many SSH keys and you may not want all of them to be associated with the instance.

[david-crespo]

If a user has SSH keys and the image they're booting supports cloud-init, the SSH keys will be automatically injected into the running instance. Note also that if a user changes their keys (i.e. adds a key, or removes a key because it is compromised) the keys in the instance will not be updated. Let's focus this issue on mentioning all that or linking to documentation about it.

[benjaminleonard]

We can have a stab at getting this into the instance create form.

@davepacheco @iliana Will the user have any control on the SSH keys that are injected for MVP or MVP+1? Like a checkbox for selecting/deselecting their keys.

As a sidenote, in lieu of a recovery console, do we have any mechanism for granting access to an instance if the user no longer has a key or one was never added? Would a user need to use an image they do have access to as the boot disk, add their SSH key to other disk and then restore that as boot disk?

Will we know whether a selected image will be adding the SSH key or not? We'd need some way of determining whether that image supports cloud-init or not? @zephraph at some point, might we want to grant the operator the ability to add tags / flags to an image e.g. cloud-init. Then we can include extra notices / documentation / validation? @iliana you'd probably know better whether this is even necessary, or is already just assumed to be managed by their own internal tooling.

[iliana]

Will the user have any control on the SSH keys that are injected for MVP or MVP+1? Like a checkbox for selecting/deselecting their keys.

Right now no, Nexus just picks up whatever keys the user has. (I am not sure what happens if another user stops and then starts the instance though.) I think that wiring through a key selection wouldn't be too hard but I don't know how important it is.

Would a user need to use an image they do have access to as the boot disk, add their SSH key to other disk and then restore that as boot disk?

Yep.

Will we know whether a selected image will be adding the SSH key or not? We'd need some way of determining whether that image supports cloud-init or not?

There's no way to statically analyze this. I think if we were distributing distro images at MVP we would want metadata that says "yes the cidata volume is supported, and this is the default username". Maybe this is metadata we will want people to be able to add to images they add.

I still need to work on the general "here's the twenty-seven things you need to have a good cloud image" docs still but one of those things will be interacting with cidata. And honestly that's optional; customers can set up their image to automatically join some domain or pull down SSH keys and the configs on boot, and ignore the cidata volume entirely.

[benjaminleonard]

We do now have a notice that explains the inclusion of SSH keys done in #1511.

When we do eventually have docs we can link to that. But we do already explain what's happening.

We have designs for adding a custom SSH key / adding a new one through the form. Blocked by oxidecomputer/omicron#3056. I'll make a separate issue for that, I think this can be closed.