Thoughts from a serf

cloudbaseinit

Regrettably, I have to work with Windows Server every day. I won't go into why I think this is regrettable in this post. But, one, of many, thing that sucks when running Windows Server is that so much information on the amazing world wide web is geared towards running applications on some sort of Linux. In the “put something on a server” world, some kind of Linux is the norm.

Anyway, I wanted to create a local Administrator account without having to push a password through CloudBase-Init in the user_data configuration. As an example one can do something like this:

users:
  - name: cool_boy_82
    groups: Administrators
    passwd: very-cool-and-strong-password
    ssh_authorized_keys:
      - ssh-rsa AAAB...byV

However, even if the above do work you get a little bit of a security issue with this approach. Say that you forget to reset the password you give user cool_boy_82 and you have some kind of breach. It can be possible to either read the logs from CloudBase-Init in C:\Program files\Cloudbase or to fetch the logs from the metadata service. Because if you put the password in clear text, it will be available in the logs in clear text. You might use this as a default account that you always add when you create new instances in OpenStack. Well, then you have a security issue.

Let CloudBase-Init generate user password

One solution for this is to let Cloudbase-Init to do the password generation for you. Then you retrieve it later through the magic of encryption. However, I ran into some issues. Whenever I tried to retrieve the password from the OpenStack CLI I got the following error:

b'unable to load Private Key [...] PEM routines [...]

So, something was wrong. And as so many times before, the error were somewhere behind the keyboard.

When you create an instance in OpenStack you tell it to use a ssh-key public key of your choice. The ssh-key public key can be used to encrypt the password that Cloud-Base Init generates so that ONLY the one who has access to the private key can decrypt it.

It is quite easy, but I ran in to a gotcha. Turns out that it is very important to create the ssh-key in a specific format and type of key. Also, if you password protect your private key, you can't retrieve the password from the OpenStack Horizon UI.

We need to use a ssh-key with type rsa and make sure that it is in the pem format. I use ed25519 as my type of choice. Especially after I started using a TKey from Tillitis wich only generates ed25519 keys.

So to generate a ssh-key of the correct type and format the following should suffice:

ssh-keygen -t rsa -m PEM -f "cool_boy_82"

So, then to retrieve the password generated for an instance use the OpenStack CLI with the following command:

nova get-password {instanceID} {PathTo: private key file}

So, all is well. If you simply do things the right way things work better. One thing that I do feel is not so “well” is the documentation from OpenStack and some of the OpenStack providers. I did search a hell of a lot to find information about this issue and I could not find conclusive, to me at least, information about what OpenStack required in terms of ssh-keys and formats. One good reasource is from the Swedish OpenStack provider Safespring. They have a very good blog post about ssh-keys and OpenStack.

Anyway, I put this out on the wide wide wide web to let any body else have the chance to find this quicker than I did.

#openstack #sshkey #cloudbaseinit #cloudinit #tkey #tillitis

Joakim Durehed