The idea of having a system SSH key is to support a number of real and

potential use-cases.

* The system ssh key could be used to monitor the bootstrap process, and this

would benefit the new users that don't have an existing SSH key

* Allows the api server machines to ssh to other machines in the environment

* could be used to set up ssh tunnels through a single public facing IP

address on the server

* allows juju-run commands to be run on remote machiens

Juju already creates a private key for serving the mongo database. It was an

option to also use this key, but in the end, having different keys for

different purposes just seems like a more robust idea.

A system key is generated when the environment is bootstrapped, and uploaded

as part of the cloud-init machine creation process. The public key part is

added to the authorized keys list.

This means that we need to generate an identity file and the authorized key

line prior to creating the new machine.

If subsequent state server machines are created, they also need to have the

system identity file on them. Actually, it is most likely the API server jobs

that we really care about.