2

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?

2 Answers 2

2

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.

5
  • I do have access. From my MaaS server, I can log into any node as ubuntu, e.g. juju ssh 3 or rsh 10.22.7.146 -l ubuntu. The problem is that I need the nodes to interact, and I can't rsync or rsh from node to node.
    – rmustakos
    Mar 31, 2015 at 15:12
  • Yes, which, as I've outlined above, is expected. You will need to have your charms do the heavy lifting for generating keys for the user on each node that should have access to each other node. Please see the code examples above. Mar 31, 2015 at 15:15
  • Sorry, hit enter to early - I was still understanding your scripts and framing my thoughts. Just to make sure I understand, after this, the controller should be able to hit each of the nodes, but the nodes would not be able to talk to each other? (I don't need them to) Also, if another "controller" does the same thing (using the same user), their key would be appended to the authorized keys, and both would live in harmony?
    – rmustakos
    Mar 31, 2015 at 15:46
  • I see you grep for the key to make sure you don't duplicate it. Coffee is just kicking in. Thank you, firing this up now.
    – rmustakos
    Mar 31, 2015 at 15:47
  • Update, this seems to be taking me in the direction I need. I will update later.
    – rmustakos
    Apr 1, 2015 at 20:26
1

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?

2
  • Why ed25519? It's the error that came up in the auth.log when the rsync failed. But I'm not picky - I just want my controller node to be able to rsync with the slave nodes. I'm trying Marco Ceppi's solution, below.
    – rmustakos
    Mar 31, 2015 at 17:00
  • I think I misunderstood your question and the ed25519 keys are only tangentially relevant. I'll leave my answer here for others though as it explains what's going on with them. Marco's answer seems more relevant to your question to me now. Apr 1, 2015 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.