optionally fetch public ssh keys from Launchpad when starting an instance

Note that euca-run-instance "-k" option does not use a generic public key file as its parameter... but rather the name of a keypair registered in Eucalyptus through euca-add-keypair. So you would miss the private key...

Maybe it would be simpler to support it through ec2-config ? Like having an extra option to install SSH authorized_keys from LP during boot ?

cloud-config does support passing in ssh keys. Look at http://bazaar.launchpad.net/%7Ecloud-init-dev/cloud-init/trunk/annotate/head%3A/doc/examples/cloud-config.txt for 'ssh_authorized_keys'.

I think what you're suggesting is what Dustin realized can be done. He opened bug 524226 ., with 'ssh-import-id' on it. That script would live inside the image, and then could easily be told to add authorized_keys on boot via cloud-config. The 'runcmd' format of cloud-config would make this trivial:

#cloud-config
runcmd:
 - [ su , -c, "ssh-import-id smoser kirkland", ubuntu ]

Rather, if euca-add-keypair could be pointed to an existing id file (optionally, pointing to one stored in Launchpad), that would be terrific. The fact that we have to generate a new key each time we upload an identity to EC2/Eucalyptus is terribly annoying; using an existing identity/key pair would be a huge usability improvement over ec2-api-tools.

On Mon, 22 Feb 2010, Etienne Goyer wrote:

> Rather, if euca-add-keypair could be pointed to an existing id file
> (optionally, pointing to one stored in Launchpad), that would be
> terrific. The fact that we have to generate a new key each time we
> upload an identity to EC2/Eucalyptus is terribly annoying; using an
> existing identity/key pair would be a huge usability improvement over
> ec2-api-tools.

I agree, its less than wonderful, but you have to admit that supporting on
ly launchpad as a source for keys is only slightly more useful.

The current system isn't really all that bad:

Host *.eu-west-1.compute.amazonaws.com
  IdentityFile /home/smoser/data/aws-smoser/ec2-keypair.eu-west-1.pem

I have lines like the following in my .ssh/config

Host *.eu-west-1.compute.amazonaws.com
  IdentityFile /home/smoser/.ssh/ec2-keypair.eu-west-1.pem

# for euca hosts (match however you want)
Host 192.168.2.*
  IdentityFile /home/smoser/.ssh/euca-key.pem

Then, when you create a new key with euca-add-keypair, just redirect to
/home/smoser/.ssh/euca-key.pem

Note, we now have ssh-import-lp-id in the archive. We should get this seeded as a recommends of cloud-init.

Invalidating the Eucalyptus task, nothing to be done there.

Confirming the euca2ools task, marking wishlist, per Etienne's feedback.

To Scott's point about only supporting Launchpad ... what other public ssh key server is there? I have scoured the net looking for an ssh equivalent of pgp.mit.edu and haven't found anything. Launchpad seems to be the most comprehensive (albeit Ubuntu-centric) one out there. In an case, the ssh-import package could eventually support more shell scripts similar to ssh-import-lp-id for other servers, if they crop up and users request this.

This bug was fixed in the package cloud-init - 0.5.7-0ubuntu3

---------------
cloud-init (0.5.7-0ubuntu3) lucid; urgency=low

  * debian/control:
    - recommend ssh-import, such that the ssh-import-lp-id
      utility is available in UEC images for convenient importing of
      ssh public keys stored in Launchpad, LP: #524101
    - build a transitional ec2-init package to handle the rename
      gracefully on upgrades, LP: #527187
 -- Dustin Kirkland <email address hidden> Thu, 25 Feb 2010 16:22:10 -0600

This bug was fixed in the package cloud-utils - 0.10-0ubuntu1

---------------
cloud-utils (0.10-0ubuntu1) lucid; urgency=low

  [ Scott Moser ]
  * ssh-import-lp-id: allow dss keys
  * uec-publish-tarball: add -q/--quiet flag
  * uec-publish-image:
    - remove trailing slash on bucket input which caused failed register
    - remove trailing tab in output
    - on error, make sure user sees command output
    - add -B/--device-block-mapping pass through to euca-bundle-image
  * uec-resize-image: make quiet by default, add --verbose,-v
  * uec-query-builds: support querying 'latest-ec2'

  [ Dustin Kirkland ]
  * debian/install, debian/manpages, uec-run-instances,
    uec-run-instances.1: add a wrapper for euca-run-instances that
    can easily/cleanly inject ssh keys from Launchpad.net, LP: #524101
 -- Dustin Kirkland <email address hidden> Thu, 25 Mar 2010 21:53:59 -0700

[[ FEATURE FREEZE EXCEPTION REQUEST ]]

Thierry has asked that I file a FFe in retrospect on this upload, which was perhaps more feature-full than it should have been.

My apologies to the Release Team. Part of the Server Team and the Eucalyptus team were sprinting last week, and worked our way through many bugs and issues.

Solving this bug involved adding a new utility to the cloud-utils package, namely uec-run-instances:
 * http://manpages.ubuntu.com/uec-run-instances

It's a simple python wrapper script (and manpage) that wraps euca-run-instances, but adds an additional option, -l|--launchpad-id, which is the Launchpad ID of the user who's SSH key will be inserted into the image, via the ssh-import-lp-id utility.

The benefit is that UEC users can optionally use uec-run-instances for a far more convenient mechanism to launch and instance and use their normal SSH key (rather than this key that the Cloud Controller generates for you).

cloud-utils builds, installs, and the uec-run-instances runs as designed. It does not break euca2ools, and other users are welcome to use euca-run-instances and ignore uec-run-instances.

Traditionally, a UEC user would do something like this:
  if [ ! -e ~/.euca/mykey.priv ]; then
    touch ~/.euca/mykey.priv
    chmod 0600 ~/.euca/mykey.priv
    euca-add-keypair mykey > ~/.euca/mykey.priv
  fi
  euca-run-instances -k mykey.priv emi-4BBB12CB
  ssh -i ~/.euca/mykey.priv ubuntu@10.1.1.10

Now, a user can run this against any ID in Launchpad that has a Public SSH key registered:
  uec-run-instances -l kirkland,smoser,ttx,mathiaz,zul emi-4BBB12CB

And any of kirkland,smoser,ttx,mathiaz,zul can:
 ssh ubuntu@10.1.1.10

Thanks,
:-Dustin

This looks to be reasonable in scope, low-risk, and self-contained; FFe granted.