knife-solo and data bag encryption

[rajanshah]

Hi,

Again this has nothing to do with knife-solo issue, but it has to be my understanding. At the same time, it would be great if someone can assist with following issue.

I am trying to clone private repo using chef-solo and have following setup.

1. Create a file
   EDITOR=vim knife solo data bag create test_key project
2. Get private key and remove new line
   a. pbcopy < ~/.ssh/id_rsa
   b. vi /tmp/test.key
   c. paste the key
   d. remove new line via :%s/\n/\n/
   e. copy it to test_key file, so now it will look like as follows:
   { “id”: “project”,
   “test_key”:
   }
3. It correctly creates data bag and I can see it
   a. knife solo data bag show secrets <app_name>
   b. knife solo data bag show secrets <app_name> --secret-file ~/.chef/encrypted_data_bag_secret
4. Cloning a private repo

• attributes
  default[:test][:base] = "/home/ubuntu"
  default[:test][:log_dir] = "/var/log/test"
  default[:test][:loglevel] = "info"
  default[:test][:user] = "ubuntu"

default[:test][:deploy_repo] = "[email protected]:test/test.git"
default[:test][:deploy_branch] = "master"
default[:test][:deploy_dir] = "/srv/test"

• recipes
  git "#{node[:test][:base]}/test" do
  repository "[email protected]/test.git"
  reference "master"
  action :sync
  destination "node[:test][:base]/test"
  user "#{node[:test][:user]}"
  group "#{node[:test][:user]}"
  ssh_wrapper "#{node[:test][:base]}/.ssh/git-ssh-wrapper.sh"
  timeout 300
  end

Couple observations:

1. Upon running the script, it generates decrypted private key file in ~/.ssh on server. It matches ditto with unencrypted key on client.
2. The above code gets stuck in "sync" step and generates error pertaining to "git ls-remote".

I would appreciate, if one suggests hint or suggestions on "what could be wrong" and ways to resolve it.

[matschaffer]

I'd debug a layer deeper. Can you ssh from the box to [email protected] as the user running chef? If not try adding -vvvv and see if the ssh error provides something useful.

If that works then try the git clone command next.

If that works, I'd check the wrapper. I'd also recommend doing away with the wrapper if possible. If you need it to set the key file location I'd recommend placing a ~/.ssh/config on the box to handle that part.

Give those things a try and good luck!

[matschaffer]

Oh and you may want to run unset SSH_AUTH_SOCK before running anything on the node in question. Otherwise ssh might start working if it picks up on a forwarded ssh agent coming from your workstation.

[rajanshah]

Thanks for quick response.

I performed unset SSH_AUTH_SOCK on node and try to carry out following commands:

1. Access even public repo (as user ubuntu, which will be running as chef user)

ssh -vvv [email protected]:<github_acct>/test.git
Could not resolve hostname github.com:intellimind/test: Name or service not known

1. ssh wrapper contains following content

#!/bin/sh
exec ssh -o UserKnownHostsFile=/home/ubuntu/.ssh/known_hosts -o "StrictHostKeyChecking=no" -i "/home/ubuntu/.ssh/<private_key>" "$@"

When I try ./git-ssh-wrapper.sh [email protected], it asks for the passphrase for the key
Enter passphrase for key "/home/ubuntu/.ssh/<private_key>"

Actually, the chef-solo recipe and private repo cloning used to work just fine before I changed my key so is there any easy way to verify accuracy of private key you deploy on server?

[rajanshah]

It got resolved, I had password on my private key and expected it to work.

Now, the question is:

What's the preferred approach for automated deployment keys for github?
a. password-less
b. with password

The follow-up question is, if it's option b. how one can supply passphrase to deployment key while performing automated deployment via chef.

[matschaffer]

I recommend a key with no password that's only given read permission to the
repository.

Encrypting the key then automating password injection with Chef doesn't
give you much additional security.

If you're provisioning with knife-solo and don't want to have an
unencrypted key on the box you could use a key from your workstation and
SSH forwarding as another option.

On Tuesday, 27 October 2015, rajanshah [email protected] wrote:

It got resolved, I had password on my private key and expected it to work.

Now, the question is:

What's the preferred approach for automated deployment keys for github?
a. password-less
b. with password

The follow-up question is, if it's option b. how one can supply passphrase
to deployment key while performing automated deployment via chef.

—
Reply to this email directly or view it on GitHub
#461 (comment)
.

-Mat

matschaffer.com

[rajanshah]

Yes, mainly password-less key on server can grant access to your repo. Isn't SSH forward at least more secure option?

Is there any good reference you can point to perform such SSH forwarding with knife-solo?

Thanks a lot for your help.

[matschaffer]

It adds security, but at the cost of requiring a 3rd party to perform the
provisioning. Often this is more manual than I like my infrastructure to be.

You can specify --forward-agent on any knife-solo command to enable agent
forwarding.

Note that for this to work sshd must be configured to allow it (usually
default) and sudo must be configured to allow -E to preserve the ssh
agent environment variables (probably default).

You can test it with ssh -A <host> then sudo -E git clone <repo> - if
that works, knife-solo should be able to leverage it as well in which case
you shouldn't need to place any ssh keys on the box.

Reading around bit (http://d.hatena.ne.jp/nekonokataomoi/20130527/1369673600)
seems to indicate that you may need to do a little work at the chef layer
too especially if you set a user for deployment. But I'd try it without
wrappers first.

Hope that helps. Like I said I usually opt for unencrypted keys which only
grant read access so I can't speak from first-hand experience here.

-Mat

matschaffer.com

On Wed, Oct 28, 2015 at 11:27 AM, rajanshah [email protected]
wrote:

Yes, mainly password-less key on server can grant access to your repo.
Isn't SSH forward at least more secure option?

Is there any good reference you can point to perform such SSH forwarding
with knife-solo?

Thanks a lot for your help.

—
Reply to this email directly or view it on GitHub
#461 (comment)
.