Is MaaS, juju, or the charm responsible for ssh-keygen on nodes?

Question

My MaaS system works, enlists, recruits, commissions, issues warrants, does courts martial, deploys and destroys. juju seems to work fine: bootstraps locally, installs juju-gui, my charms get deployed, units get assigned to services as I would expect, my relations are noted and hooks run and everything displays well in juju-gui.

The charms I am using are a matched controller (1) and slave (many) set. The controller should rsync between itself and each of the slaves. What happens is that the slaves reject the attempt, complaining that they are unable to open the sseh_host_ed25519_key file. (tail -f /var/log/auth.log) (I am running script, not charm yet, I rsh'd to the controller as ubuntu, and am running it from there)

I read that the answer is fairly simple, do ssh-keygen -a on each machine. First, I run this on the controller and then on the slave. I try the rsync, auth.log says connection closed by [preauth]. I try ssh_copy-id, but it gets "Permission denied. (Publickey)", same entry in the auth.log.

So, my questions: Where do I put the ssh-keygen to get it to work? What am I missing in distributing the keys that is hosing me?

Answer 1

MAAS will make sure /you/ have access to each node by adding the key that Juju tells it (and that key is only your public-key). Units do not have SSH access to themselves by design (think of the security implications!).

If you wanted to make it so that all units or services can access each other you need to have each machines generate an SSH key for the user you wish to interface then send their public ssh-key to each other via the relation. So if this is for a master -> slave setup here is how you would do something like that:

master-charm/metadata.yaml

name: master-charm
provides:
  master:
    interface: my-charm-interface

slave-charm/metdata

name: slave-charm
requires:
  master:
    interface: my-charm-interface

Then in each charm, you'll need to do something like the following:

(master|slave)-charm/hooks/master-relation-joined

#!/bin/bash

if [ ! -f ~user-you-want-access/.ssh/id_rsa ]; then
  ssh-keygen -t rsa -N "" -f ~user-you-want-access/.ssh/id_rsa
  chown -R user-you-want-access.user-you-want-access ~user-you-want-access/.ssh
fi

relation-set public-key="$(cat ~user-you-want-access/.ssh/id_rsa.pub)"

(master|slave)-charm/hooks/master-relation-changed

#!/bin/bash

key="$(relation-get public-key)"

if [ ! -z "$key" ] && ! grep -q "$key" ~user-you-want-access/.ssh/authorized_keys; then
  echo "$key" >> ~user-you-want-access/.ssh/authorized_keys
  chown -R user-you-want-access.user-you-want-access ~user-you-want-access/.ssh
fi

These are just meant to stub out how you would model something like this. You could do the same thing for access between nodes themselves using the peer relations.

Answer 2

In answer to your general question, the cloud-init package is responsible for generating host keys during first boot on cloud images.

In your more specific case, I don't think it currently generates ed25519 keys, but this hasn't been known to cause any issues for any users. If it does cause a problem for you, you should note your use case in more detail in bug 1382118. Why do you specifically need ed25519 anyway?