Hi Kevin,Thanks for sharing your thoughts. Let me describe my scenario and what I'm trying to accomplish.I have VMs that spin up automatically on AWS. These VMs host several applications, most written in PHP and RoR. The source code for all the apps resides on bitbucket Git repos.I'm setting up application deployment via the deploy resource [0]. For that, I have created a "deploy" user through the users cookbook, but I need this user to have read-only access to the repos. For that, I have a bitbucket user with read-only access and I need to configure this user with the public keys, and that's done on bitbucket website.If I create a new key pair on each VM, I'll have to manually authorise the new key on the bitbucket website so that the application can be deployed. That would completely defeat auto-scaling and would make my life a bit worse, specially on peak times. :)I understand the security implications of this approach, but I still find it all that much better than having to manage potentially infinite key pairs on a website. This key would have read only access to our repos, and if I find out that it has been compromised all I need to do is revoke it on bitbucket, create a new key pair and redistribute it.I can do that on a recipe manually, but it would be just a bit easier and more concise if it was possible via the users cookbook.Also, it beats me why the cookbook allows me to distribute private keys via an unencrypted data bag [1], and has no secure-ish solution for that.Again, I'm open for hearing other solutions to this problem. If they're more secure, all the better, as long as it doesn't make me go to bitbucket.org and insert a new pubkey each time I spin up a new server. :)- cassianoOn Thursday, January 10, 2013 at 09:51, Kevin Keane (subscriptions) wrote:
It seems to me that there might be a problem with what you are trying to accomplish in the first place. When you distribute private SSH keys through *any* means, you have a security problem. Doesn't matter if you are using encrypted databags, or even manually copy the keys over. Unless they are your own personal keys, it defeats the very concept behind public key encryption - and if they *are* your personal keys, you should only manually copy them, not put them in an automated distribution system.
Once generated, private SSH keys should never leave that user's control. You can use chef to distribute the corresponding public keys - and you don't even need an encrypted databag. Public keys are not sensitive; you can leave them unencrypted.
If your users are humans, have them generated their SSH key pairs, and create a databag with all the public keys that you want to distribute. Hint: the users cookbook already has a mechanism built in to do that.
If you need SSH key pairs for some automated tasks (say, a cron script doing a nightly rsync), generate a *new* key pair, and store only the public key in a node attribute. You can use an execute or script resource to generate the key pair; just make sure to check if the key may already exist (you don't want to clobber an already-existing key pair).
On the SSH client side, you'd extract all the relevant public keys from your databag or node attributes, and add them to the authorized_keys file as needed.
-----Original message-----
From: Cassiano Leal < " target="_blank"> >
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: " target="_blank"> ;
Hi!Is there a way to securely distribute private ssh keys through the users community cookbook?In my setup I have a user deploy that will fetch from git, and I need that user to have a SSH key that's authorized on the git repo. I saw that the users cookbook will use "ssh_private_key" and "ssh_public_key" data bag items, but those would be unencrypted, so not secure.If people are using a different approach, I'd like to hear about that too.Thanks!--Cassiano Leal
Archive powered by MHonArc 2.6.16.