Storing private ssh keys in variables

I’m trying to store ssh private keys in variables in a vault-protected file, and I’m having problems. The issue is with the variables spanning many lines, when they are injected during the playbook run, on the destination server they end up in a mangled format or the playbook crashes out. So for example, in my vars file (this is a key I just generated and deleted to demo it here):

id_dsa: “-----BEGIN DSA PRIVATE KEY-----
MIIBuwIBAAKBgQC4ZqbQspFVSqjJmLbyve+5/NG0oGLa6GMd3pctilZkUcyld/k+
j07TROjQLsSbDiweUa5HKBVSTuoHSLAq7V8vr3DSV2T/bX325STgo/0vkIJeZmcr
1eZiBQyPRMtbVORxbfBI94ofL52C381eRxNhNgr27FUxJPaP0AelmrNtHwIVAI4R
MwoEbRbqBFzwC1lPvV4XrkU3AoGANSGsM0gWzFDUL3o3KpKbGehfAXdKDjGms3FN
r9itrMVy1klErQ9GHOeyGRD+Pkr4LDP7CUELpR58/Yv9358tkkffSpHqstuvgX1k\n
I12214Wk/VqjOBaQhZDa6FwM3wrPAztGAZChvj5BdRQDqh77x9ljBWE8psfZ+TRe
SBvMQ7cCgYAOUWMQdc3RYc/+HuKf8d0ke5ecFXSnpkrNt0spJdviMl0ui8n6aPOy
rP/5FGpzR8to8/xGnpD6RdEFuSTABDHR85Y9pLmts1Zf1ctGMcxXiPsjunHfX/GI
fc6sVh556dgAf7a33aEPjqw7Ll+q9rTq6OFSgL14B1y8Gs2EbyjH6AIVAIQndtm5
YhlFBaJk02PRX3zKorL6
-----END DSA PRIVATE KEY-----”

in my playbook:

  • name: push out ssh private keys
    shell: ‘echo -e “{{ item.value }}” > /home/hcom/.ssh/{{ item.name }}’

with_items:

  • { name: “id_dsa”, value: “{{ id_dsa }}” }
  • { name: “id_rsa”, value: “{{ id_rsa }}” }

I’ve tried adding \n on the end of each line in my key, I’ve also tried all on one line with \n separators.

I’m getting this error:

fatal: [127.0.0.1] => A variable inserted a new parameter into the module args. Be sure to quote variables if they contain equal signs (for example: “{{var}}”).

Any pointers would be cheerfully accepted. I’m interested to hear how others have tackled this issue.

Thanks
Ben

It seems better to password protect the key itself IMHO.

That way it’s still secure even outside of vault, and you can just use the file lookup to pass to the authorized key module.

You can also then use the more obvious “copy” module to move the files around.

This is the use case for which I added vault support to the file lookup plugin
https://github.com/ansible/ansible/pull/8110

Yep, this is likely going merged and quite good stuff, but others should be aware lookup plugins evaluate every time the template strings are rendered.

You could, depending on usage, make the system do a LOT of math if you aren’t careful.

I think we do something similar with SSL certificates.

First, we use the multi-line YAML notation ni the vars file:
ssl_private_key: |
-----BEGIN RSA PRIVATE KEY-----
ETC…

Note the spacing in front of the lines, that’s required.
In case you don’t need the actual newlines on the other end, you can also use “>” instead of “|”

And then we have a template “templates/ssl_private_key.j2” with just the variable as content:
{{ ssl_private_key }}

Thanks, I guess this is what I am looking for and I’ll wait for this patch to be merged.

It resolves another thing I was surprised about, if I encrypt whole files with ansible-vault, during the playbook run with --ask-vault-pass the files are still not parsable because they are still encrypted. I suppose this is by design but doesn’t do what I wanted or expected.

Michael I will go with your suggestion for now and use something external to protect the private keys. I did find the authorized keys module but the docs only mention use cases for public keys so I didn’t explore it any further.

Cheers

" during the playbook run with --ask-vault-pass the files are still not parsable because they are still encrypted"

Ansible-vault only applies to ansible variable files, task files, and handlers. Basically anything Ansible would understand to be natively-understood YAML files.

I do something similar to this to store sensitive files in vault. I base64 encode the data and set the variable with the resulting encoded string. Then in my template I use the b64decode filter when applying the variable.

in your vault file

private_key: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1J…

then in your private_key template add

{{private_key | b64decode}}

This has worked very well for me this far.

thanks,

Steve.