This is the output of juju from a clean install with 2 nodes all running 12.04 juju bootstrap - finishes with no errors and allocates the machine to the user but still no joy after juju environment-destroy and rebuild with different users and different nodes.

root@cloudcontrol:/storage# juju -v  status
2012-06-07 11:19:47,602 DEBUG Initializing juju status runtime
2012-06-07 11:19:47,621 INFO Connecting to environment...
2012-06-07 11:19:47,905 DEBUG Connecting to environment using node-386077143930...
2012-06-07 11:19:47,906 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="node-386077143930" remote_port="2181" local_port="57004".
The authenticity of host 'node-386077143930 (' can't be established.
ECDSA key fingerprint is 31:94:89:62:69:83:24:23:5f:02:70:53:93:54:b1:c5.
Are you sure you want to continue connecting (yes/no)? yes
2012-06-07 11:19:52,102 ERROR Invalid SSH key
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@662: Client environment:host.name=cloudcontrol
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@669: Client environment:os.name=Linux
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@670: Client environment:os.arch=3.2.0-23-generic
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@671: Client environment:os.version=#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@679: Client environment:user.name=sysadmin
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@687: Client environment:user.home=/root
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@699: Client environment:user.dir=/storage
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@zookeeper_init@727: Initiating client connection, host=localhost:57004 sessionTimeout=10000 watcher=0x7feb11afc6b0 sessionId=0 sessionPasswd=<null> context=0x2dc7d20 flags=0
2012-06-07 11:19:52,429:18541(0x7feb0e856700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
2012-06-07 11:19:55,765:18541(0x7feb0e856700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
  • I have tried numerous ways of creating the keys with ssh-keygen -t rsa -b 2048, ssh-keygen -t rsa, ssh-keygen, and i have tried adding those to MAAS web config page, but always get the same result.
  • I have added the appropriate public key afterwards to the ~/.ssh/authorized_keys
  • I can also ssh to the node, but as I have not been asked to give it a user name or password or set up any sort of account, I cannot manually ssh into the node. The setup of the node is all handled by maas server. It seems like a simple error of looking at the wrong key or looking in the wrong places, only other suggestions I can find are to destroy the environment and rebuild (but that didn't work umpteen times now) or leave it to build the instance once the node has powered up, but I have left for a few hours, and left overnight to build with no luck.

4 Answers 4


The solution I came up with is to set a password for the newly-booted nodes, and then manually insert SSH keys into each of them. To set a boot password for the ubuntu user, ensure that the following lines to /var/lib/cobbler/kickstarts/maas.preseed:

d-i    passwd/make-user boolean true
d-i    passwd/user-fullname ubuntu
d-i    passwd/username string ubuntu
d-i    passwd/user-password-crypted password <CRYPTED PASSWORD>

Once this is done, you can ssh ubuntu@ and use the password specified in the crypted password string (easiest way is to use one from an /etc/shadow file you already know) to log in. You can then insert your SSH public keys under ~ubuntu/.ssh/authorized_keys and ~root/.ssh/authorized keys.

Note that this is a workaround- once you ssh-keygen, MaaS should either be pulling the id_rsa.pub from your .ssh directory, or from the MaaS WebUI, where the user can specify a public key in his profile. No matter what I've tried, these keys aren't propagated, so I came up with the workaround.

A further cheat is to just add the .pub key to your MaaS node's .ssh/authorized_keys and then scp it to each of the nodes in the MaaS:

for i in `cobbler system list |grep -v default`; 
    do j=`cobbler system dumpvars --name "${i}" | grep hostname |grep -v duplicate |cut -f 2 -d \:`; 
    scp ~/.ssh/authorized_keys ubuntu@${j}:.ssh/authorized_keys;

This leaves you able to just repeatedly accept the SSH certificate errors and type the password in the crypted string to populate your entire MaaS with the SSH public key.

  • One note- the reason for my SSH key propagation issues was hostname resolution on my MaaS node, which is dual-homed- make sure your MaaS node's hostname in /etc/hostname resolves to the MaaS network IP (internal IP) of the MaaS node- that may require putting a different hostname (I use -pub) on the Public IP interface of a dual-homed MaaS node.
    – cheez0r
    Jun 20, 2012 at 17:04
  • Yup, does that, all traffic is routed through MAAS server, MAAS node gets all network setup from DHCP off the MAAS server. Both Server and node resolve hostnames, local, domain, and internet.
    – Captain T
    Jun 22, 2012 at 10:42

Ensure that you're generating your SSH keys on the same host as you're using juju from, and add the public half of your SSH key(s) on that machine into MAAS (try: ls ~/.ssh/*.pub to find them all). There shouldn't be any need to manually put keys into ~/.ssh/authorized_keys.

The getting started with Juju guide may help if you've not seen that.

  • Yup Tried that and that is the guide i was following. So i am thinking it must be a hardware to software glitch on my systems ??? I have read about others with the same problems, and obviously there are many installs for people who have no errors at all.
    – Captain T
    Jun 22, 2012 at 10:45

I'm facing the same problem. Two days ago I started to look out for a answer and the most significant thing I found out is this:

When running "juju status" you may encounter an error that says "Invalid SSH key"

The most likely source of this error is that the nodes that juju started up have not finished booting and installing yet. This can happen when the clock on the node is too far out of sync for the OAuth verification to work, which results in the node timing out when trying to download from the metadata service and eventually continues booting to a login prompt without running the Juju preseed.

Try checking the clock on the node and reset it if it's very different from the MAAS server's clock.


This really fixed this problem. I ran ntpdate on my MAAS server and installed the new node, now works great!


Ensure that you leave plenty of time for the node to install after bootstrap; it can take 10s of minutes to complete the Ubuntu installation. The error messages appear to indicate that juju is trying to connect to a machine that is not yet running sshd, which to me indicates that the installer is probably still running.

  • I have left for periods of 1hr, 4hr, over night and 24hr, just to be sure. I think sshd is running because if i manually ssh to the nodes it asks for passwords, but as i haven't set any users details so i can not log in. Maybe it has crashed at some point on the install between setting up sshd and completing ???
    – Captain T
    Jun 22, 2012 at 10:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .