[openstack-dev] Supporting SSH host certificates
Giuseppe de Candia
giuseppe.decandia at gmail.com
Fri Sep 29 20:05:11 UTC 2017
Ihar, thanks for pointing that out - I'll definitely take a close look.
Jon, I'm not very familiar with Barbican, but I did assume the full
implementation would use Barbican to store private keys. However, in terms
of actually getting a private key (or SSH host cert) into a VM instance,
Barbican doesn't help. The instance needs permission to access secrets
stored in Barbican. The main question of my e-mail is: how do you inject a
credential in an automated but secure way? I'd love to hear ideas - in the
meantime I'll study Ihar's link.
On Fri, Sep 29, 2017 at 2:49 PM, Ihar Hrachyshka <ihrachys at redhat.com>
> What you describe (at least the use case) seems to resemble
> https://review.openstack.org/#/c/456394/ This work never moved
> anywhere since the spec was posted though. You may want to revive the
> discussion in scope of the spec.
> On Fri, Sep 29, 2017 at 12:21 PM, Giuseppe de Candia
> <giuseppe.decandia at gmail.com> wrote:
> > Hi Folks,
> > My intent in this e-mail is to solicit advice for how to inject SSH host
> > certificates into VM instances, with minimal or no burden on users.
> > Background (skip if you're already familiar with SSH certificates):
> > host certificates, when clients ssh to a host for the first time (or
> > the host has been re-installed), they have to hope that there's no man in
> > the middle and that the public key being presented actually belongs to
> > host they're trying to reach. The host's public key is stored in the
> > client's known_hosts file. SSH host certicates eliminate the possibility
> > Man-in-the-Middle attack: a Certificate Authority public key is
> > to clients (and written to their known_hosts file with a special syntax
> > options); the host public key is signed by the CA, generating an SSH
> > certificate that contains the hostname and validity period (among other
> > things). When negotiating the ssh connection, the host presents its SSH
> > certificate and the client verifies that it was signed by the CA.
> > How to support SSH host certificates in OpenStack?
> > First, let's consider doing it by hand, instance by instance. The only
> > solution I can think of is to VNC to the instance, copy the public key
> to my
> > CA server, sign it, and then write the certificate back into the host
> > via VNC). I cannot ssh without risking a MITM attack. What about using
> > user-data? User-data is exposed via the metadata service. Metadata is
> > queried via http (reply transmitted in the clear, susceptible to
> > and any compute node can query for any instance's meta-data/user-data.
> > At this point I have to admit I'm ignorant of details of cloud-init. I
> > cloud-init allows specifying SSH private keys (both for users and for SSH
> > service). I have not yet studied how such information is securely
> > into an instance. I assume it should only be made available via
> > rather than metadata-service (again, that service transmits in the
> > What about providing SSH host certificates as a service in OpenStack?
> > keep out of scope issues around choosing and storing the CA keys, but
> the CA
> > key is per project. What design supports setting up the SSH host
> > automatically for every VM instance?
> > I have looked at Vendor Data and I don't see a way to use that, mainly
> > because 1) it doesn't take parameters, so you can't pass the public key
> > and 2) it's queried over http, not https.
> > Just as a feasibility argument, one solution would be to modify Nova
> > instance boot code. Nova compute can securely query a CA service asking
> > a triplet (private key, public key, SSH certificate) for the specific
> > hostname. It can then inject the triplet using ConfigDrive. I believe
> > securely gets the private key into the instance.
> > I cannot figure out how to get the equivalent functionality without
> > modifying Nova compute and the boot process. Every solution I can think
> > risks either exposing the private key or vulnerability to a MITM attack
> > during the signing process.
> > Your help is appreciated.
> > --Pino
> > ____________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev