Need downloadable link for private keys

This is true, however I don't think we can get the private key afterwards from nova unfortunately.

Confirmed that nova only returns the private key on creation and it's not retained. The private key is downloaded automatically on creation anyways, so hard to forget. ;)

That's a feature, not a bug. We really don't want nova to retain private keys. Even generating them server-side is not ideal from a security perspective, but is a compromise for convenience. At one point pre-keystone I remember a discussion about using javascript to do key generation so the client's private key never touched the server. However, an alternative key rescue approach might be to allow a new public key to be injected into a running instance?

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
<email address hidden>
ph: 443-274-6064 fx: 443-274-6060

On May 27, 2012, at 2:09 PM, Mike Perez wrote:

> Confirmed that nova only returns the private key on creation and it's
> not retained. The private key is downloaded automatically on creation
> anyways, so hard to forget. ;)
>
> --
> You received this bug notification because you are subscribed to
> OpenStack Dashboard (Horizon).
> https://bugs.launchpad.net/bugs/1004380
>
> Title:
> Need downloadable link for private keys
>
> Status in OpenStack Dashboard (Horizon):
> Confirmed
>
> Bug description:
> Currently you can only download the ssh private key once you created
> a new keypair. If you forget to download it or delete the downloaded
> key file by mistake, you won't be able to get it via a downloadable
> link. This is not convenient for user.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/horizon/+bug/1004380/+subscriptions

From security perspective, it would be better to leverage PKI to protect and retain private keys if possible. This seems to complicate this feature.
another approach is provide user an option (disable by default) to save the private key in system for download with some warning message for security compromise to do this. To protect these keys in system, a pin code could be used to encrypt/decrypt the private key. Once the key pair generated, provide user a destroy link to erase the private key from system, a download link for private key protected by the pin code. It would be easier to manager lots of keys with this feature in some cases.

Current design of the keypair download link doesn't work if the private key file is not saved automatically. Click the link, you'll get an error like this:
Error: Unable to create keypair: Key pair 'demokey' already exists. (HTTP 409) (Request-ID: req-35f28aea-4b43-4bed-9168-d9400e4de08e)
It is a little confusing here.

The solutions being discussed are now in the realm of Nova and Keystone, so I'm adding those projects to this bug report.

For Horizon this is 100% a wontfix. We're not ever going to store a user's private key file.

In the V3 API for Keystone (starting implementation now - in Folsom release timeframe), there's an explicit set up for storing and retrieving credentials. Once that aspect of the API is available, this kind of feature will be able to be implemented in Horizon, and used as a service by Nova over the current mechanisms it has for dealing with the keypairs.

Looks like the fix belongs to Keystone... reopen Nova task if anything needs to be done on Nova's side

Identity API v3 introduced a /v3/credentials API that could be utilized for this purpose, with proper adjustments to policy.json (only the owning user should be able to download a private key, for example. policy.json is also now capable of filtering by both owning user ID and credential type.