google_key_pair resource should work when only existing public key is specified

[rmoriz]

Hi,

why is a private key generated, if I only specify a public key?

As far as I understand it's just compied to the compute instances for enabling key based login. I'm happy with re-using my default ssh key combination and I don't want to specify "-i /path/to/google_default" all the time.

What am I missing here?

Thanks :)

[erjohnso]

Hi @rmoriz,

It sounds like this may just be a bug if I understand correctly. Can you provide a recipe snippet and the command you're using?

Also, this is just the very early stages work for chef-provisioning supporting Google. I'd call it version 0.0.0 at this point and I suspect quite a few iterations as development starts really picking up in the next month or two. We'd definitely welcome feedback / suggestions on how to improve it!

Cheers!

[rmoriz]

relevant code is https://gist.github.com/rmoriz/f293ca1402591c5469ae#file-test-rb-L29-L35

I'm used to just provide public keys to other cloud vendors, e.g. DigitalOcean, to be installed on the generated VM.

[erjohnso]

Ah, I think I understand your point now. Essentially, you'd like to use an existing key (even if you'd stil be required to specify a path to the public key)?

I'm assuming you tried leaving out private_key_path and pointing public_key_path to an existing public key? It's a little unclear just skimming the code, but I suspect that won't work.

I'm not familiar with the details of how other providers set up SSH access to VMs. But on GCE, a new VM will query the internal metadata server (169.254.169.254) for a special metadata key-pair called 'sshKeys'. This is a list of public SSH keys that get dropped into the appropriate user's ~/.ssh/authorized_keys file. For you to SSH to the VM, you'll need the corresponding private key on your local system. If you were strictly using the Cloud SDK[1] gcloud compute ssh command to access your VMs, it will automatically create a key pair named ~/.ssh/google_compute_engine[.pub] and upload the public key to the GCE metadata server. With the gcloud compute ssh command, it will (be default) use that key pair for SSH access.

The Chef provisioner plugin for Google does something similar, but creates a new key pair.

I recall talking this over a bit with Tyler and if I remember correctly, his thinking was that users would want a separate chef+gce key pair to distinguish it from any other ssh keys you might have (either in or out of GCE).

@tyler-ball - did I get that right?

[rmoriz]

The problem with an extra keypair is, that I need to change all knife, ssh, rsync… tasks to use the extra gce keypair or roll out a custom ~/.ssh/config with all GCE nodes.

I still don't understand why I need to provide a private key to GCE/chef-provisioning-google… For me chef-provisioning-google should just use/upload the default public key of the current user.

I'm new to GCE, using AWS, DigitalOcean and other providers. AWS just needs a public key http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#how-to-generate-your-own-key-and-import-it-to-aws - So IMHO chef-provisioning-google should accept a single public key and default to the current local user's.

pseudo code:

  google_key_pair "#{ENV['USER']}" do
    public_key_path "~/.ssh/id_(rsa|dsa).pub"
  end

[tyler-ball]

You shouldn't have to generate a new private key or public key - if you point the paths to an existing key pair it should just use those.

The behavior in chef-provisioning-aws is to automatically generate a private key (or use the existing one) in ~/.chef/keys/chef_default if you don't specify a key pair.

I don't know that its safe to assume a production cloud-provisioning machine will have the same keys from other tools (like knife or rsync) installed.

One of the goals of chef-provisioning is to make sure machine 'test' correctly compiles and converges, using sane defaults. Because we already have precedence with chef-provisioning-aws I would like to see the default be to use ~/.chef/keys/chef_default as the default key if one isn't specified.

I'm not completely set on this though - if we decide it makes more sense to use ~/.ssh/id_(rsa|dsa).pub as the default than we could do that for chef-provisioning-google.

In your case, I think your recipe would look like this:

google_key_pair "#{ENV['USER']}" do
  private_key_path "~/.ssh/id_rsa"
  public_key_path "~/.ssh/id_rsa.pub"
  allow_overwrite false # false is the default, just putting this here for illustration
end

with_machine_options key_name: "#{ENV['USER']}"

machine 'testnginx01' do
  machine_options(
    insert_options: {
      machineType: 'zones/europe-west1-d/machineTypes/f1-micro',
      scheduling: {
        preemptible: true # save money while testing
      }
    }
  )
end

Does this make sense? The with_machine_options will set the default key so all machines which don't overwrite it will use that.

I agree with you that GCE only needs to know about the public key. In this case, if there was an existing public key locally then the following should work:

google_key_pair "#{ENV['USER']}" do
  public_key_path "~/.ssh/id_rsa.pub"
end

If that doesn't work then we should update this issue to encompass that - you shouldn't need to specify private_key_path if you specify public_key_path as an existing public key.

[rmoriz]

@tyler-ball iirc it didn't work by just specifying the public key. https://github.com/chef/chef-provisioning-google/blob/master/lib/chef/provider/google_key_pair.rb seems to enforce the ~/.chef/keys/<key> logic…

[tyler-ball]

Then I think thats what this issue should focus on - making chef_key_pair work when only an existing public key is specified. That should be easy to test and verify.