[openstack-dev] Supporting SSH host certificates
Giuseppe de Candia
giuseppe.decandia at gmail.com
Fri Sep 29 20:20:48 UTC 2017
Hi Ihar,
I have reviewed https://review.openstack.org/#/c/456394/ (Fetch hostkey
from port) and noted that:
1) that discussion is likely to stay among the Neutron developers only
(whereas I would like a wider audience, especially including Nova
developers)
2) that proposal does not consider SSH certificates, which are becoming a
standard approach in the industry (see [1] and [2])
Therefore, I would like to keep the discussion here.
thanks,
Pino
[1] -
https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/
[2] -
https://medium.com/uber-security-privacy/introducing-the-uber-ssh-certificate-authority-4f840839c5cc
On Fri, Sep 29, 2017 at 3:05 PM, Giuseppe de Candia <
giuseppe.decandia at gmail.com> wrote:
> 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.
>
> thanks,
> Pino
>
>
>
> On Fri, Sep 29, 2017 at 2:49 PM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
>
>> 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.
>>
>> Ihar
>>
>> 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):
>> without
>> > host certificates, when clients ssh to a host for the first time (or
>> after
>> > 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
>> the
>> > 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 of
>> > Man-in-the-Middle attack: a Certificate Authority public key is
>> distributed
>> > to clients (and written to their known_hosts file with a special syntax
>> and
>> > 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
>> host
>> > 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
>> (again
>> > via VNC). I cannot ssh without risking a MITM attack. What about using
>> Nova
>> > user-data? User-data is exposed via the metadata service. Metadata is
>> > queried via http (reply transmitted in the clear, susceptible to
>> snooping),
>> > 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
>> know
>> > cloud-init allows specifying SSH private keys (both for users and for
>> SSH
>> > service). I have not yet studied how such information is securely
>> injected
>> > into an instance. I assume it should only be made available via
>> ConfigDrive
>> > rather than metadata-service (again, that service transmits in the
>> clear).
>> >
>> >
>> >
>> > What about providing SSH host certificates as a service in OpenStack?
>> Let's
>> > 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
>> certificate
>> > 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
>> out;
>> > and 2) it's queried over http, not https.
>> >
>> >
>> >
>> > Just as a feasibility argument, one solution would be to modify Nova
>> compute
>> > instance boot code. Nova compute can securely query a CA service asking
>> for
>> > a triplet (private key, public key, SSH certificate) for the specific
>> > hostname. It can then inject the triplet using ConfigDrive. I believe
>> this
>> > 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
>> of
>> > 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.op
>> enstack.org?subject:unsubscribe
>> > 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/85ba19da/attachment.html>
More information about the OpenStack-dev
mailing list