GCE service account: "RSA key format is not supported"

Hi,

I'm running

$ ansible --version
ansible 1.7 (devel 74f20ebf79) last updated 2014/06/04 11:36:10 (GMT -400)

on a week-old OpenBSD snapshot.

I'm trying to get Google Compute Engine running with a service
account, following instructions from:

http://docs.ansible.com/guide_gce.html

I have one test instance up, just so Ansible can see it. When I run
gce.py, I get:

$ ./gce.py --list
Traceback (most recent call last):
  File "./gce.py", line 257, in <module>
    GceInventory()
  File "./gce.py", line 101, in __init__
    self.driver = self.get_gce_driver()
  File "./gce.py", line 157, in get_gce_driver
    gce = get_driver(Provider.GCE)(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/libcloud/compute/drivers/gce.py", line 536, in __init__
    super(GCENodeDriver, self).__init__(user_id, key, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/libcloud/compute/base.py", line 636, in __init__
    api_version=api_version, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/libcloud/common/base.py", line 950, in __init__
    self.connection = self.connectionCls(*args, **conn_kwargs)
  File "/usr/local/lib/python2.7/site-packages/libcloud/compute/drivers/gce.py", line 75, in __init__
    **kwargs)
  File "/usr/local/lib/python2.7/site-packages/libcloud/common/google.py", line 523, in __init__
    self.token_info = self.auth_conn.get_new_token()
  File "/usr/local/lib/python2.7/site-packages/libcloud/common/google.py", line 438, in get_new_token
    key = RSA.importKey(self.key)
  File "/usr/local/lib/python2.7/site-packages/Crypto/PublicKey/RSA.py", line 682, in importKey
    raise ValueError("RSA key format is not supported")
ValueError: RSA key format is not supported

Any idea why?

My config files follow (I've made minor changes to obfuscate actual
project numbers and such, but the number of characters all stays the
same):

My gce.ini is:

$ grep -v ^# gce.ini
[gce]
libcloud_secrets = /etc/ansible/secrets.py

secrets.py is:

GCE_PARAMS = ('764898231355-irjfbhu4jv3ihrnh1klar9egfiib2t4d@developer.gserviceaccount.com', '/home/ansible/gce-cert.pem')
GCE_KEYWORD_PARAMS = {'project': 'vast-service-302'}

I created the PEM file with:

$ openssl.exe pkcs12 -in 4f5c41f18ceeed58b36e4cd77c7c40ce8fee55c6-privatekey.p12 -nodes -nocerts | openssl rsa -out gce-key3.pem
Enter Import Password:
MAC verified OK
writing RSA key
$

And the file gce-cert.pem contains:

-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQC3hj9hSQjC211qbEK6yMepjeIv53DF0OdkJI1TynH5UN0er4BN
7jnOaGf/BWrwIIKFbLrbSF9XlDjJ4PA+PLzQCmSGRwI4+OOZ/1TRyom+Wpv9owRl
...
rmc86L3+SpMdc4ZfmwJAM60M4jCeKh+ZEWqUvhTVFvaOM1VXVAEJCIs5nvIL8Vao
nzSQW7YBrjlG7/o0AaTJEJaVN8KXQgkS0etKUFOHnA==
-----END RSA PRIVATE KEY-----

Having read the archives on this error message:

I'm pretty confident that this is an actual RSA key, as file(1)
recognizes it as such.

The OpenBSD box has py-libcloud-0.14.1.

The Ansible host can talk to Google Cloud -- I can run gcutil as
ansible, with it logged in using my Google account. But I'd really
rather use the service account for this.

Any suggestions?

==ml

I don’t know about this one, maybe some of the GCE folks involved with the module can chime in.

A traceback is very much a bug, so please make sure one is filed and we can get Eric Johnsons’s attention on it on GitHub.

Hi Michael (Lucas),

First, I’d suggest deleting that service account and creating new one since I believe you’ve shared a bit too much information. :slight_smile:

As for the traceback, I’m not sure what you’re getting that error. It looks like you’ve done everything to get set up just fine. I’ve never tried this on a FreeBSD system, so I’ll see if I can fire up an instance with that and see if I can replicate. I’ll follow up by Monday.

But do whack those credentials straight away!

Eric

I should have mentioned, those credentials were changed for just that reason… altered many characters to obscure them, but left them the exact same length and format.

Just updated Ansible and tried again, same result.

Issue #7845 filed.