<div dir="ltr">Hi Clint,<div><br></div><div>Isn't user-data by definition available via the Metadata API, which isn't considered secure:</div><div><a href="https://wiki.openstack.org/wiki/OSSN/OSSN-0074">https://wiki.openstack.org/wiki/OSSN/OSSN-0074</a><br></div><div><br></div><div>Or is there a way to specify that certain user-data should only be available via config-drive (and not metadata api)?</div><div><br></div><div>Otherwise, the only difference I see compared to using Meta-data is that the process you describe is driven by the user vs. automated.</div><div><br></div><div>Regarding the extra plumbing, I'm not trying to avoid it. I'm thinking to eventually tie this all into Keystone. For example, a project should have Host CA and User CA keys. Let's assume OpenStack manages these for now, later we can consider OpenStack simply proxying signature requests and vouching that a public key does actually belong to a specific instance (and host-name) or Keystone user. So what I think should happen is when a Project is enabled for SSHaaS support, any VM instance automatically gets host certificate, authorized principal files based on Keystone roles for the project, and users can call an API (or Dashboard form) to get a public key signed (and assigned appropriate SSH principals).</div><div><br></div><div>cheers,</div><div>Pino</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 6, 2017 at 2:37 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A long time ago, a few Canonical employees (Scott Moser was one of them,<br>
forget who else was doing it, maybe Dave Walker and/or Dustin Kirkland)<br>
worked out a scheme for general usage that doesn't require extra plumbing:<br>
<br>
 * Client generates a small SSH host key locally and pushes it into<br>
   user data in a way which causes the image to boot and install this<br>
   key from user_data as the host SSH key.<br>
 * Client SSH's in with the strict requirement that the host key be the<br>
   one they just generated and pushed into the instance.<br>
 * Client now triggers new host key generation, and copies new public<br>
   key into client known_hosts.<br>
<br>
With this system you don't have to scrape console logs for SSH keys or<br>
build your system on hope.<br>
<br>
Excerpts from Giuseppe de Candia's message of 2017-09-29 14:21:06 -0500:<br>
<div class="HOEnZb"><div class="h5">> Hi Folks,<br>
><br>
><br>
><br>
> My intent in this e-mail is to solicit advice for how to inject SSH host<br>
> certificates into VM instances, with minimal or no burden on users.<br>
><br>
><br>
><br>
> Background (skip if you're already familiar with SSH certificates): without<br>
> host certificates, when clients ssh to a host for the first time (or after<br>
> the host has been re-installed), they have to hope that there's no man in<br>
> the middle and that the public key being presented actually belongs to the<br>
> host they're trying to reach. The host's public key is stored in the<br>
> client's known_hosts file. SSH host certicates eliminate the possibility of<br>
> Man-in-the-Middle attack: a Certificate Authority public key is distributed<br>
> to clients (and written to their known_hosts file with a special syntax and<br>
> options); the host public key is signed by the CA, generating an SSH<br>
> certificate that contains the hostname and validity period (among other<br>
> things). When negotiating the ssh connection, the host presents its SSH<br>
> host certificate and the client verifies that it was signed by the CA.<br>
><br>
><br>
><br>
> How to support SSH host certificates in OpenStack?<br>
><br>
><br>
><br>
> First, let's consider doing it by hand, instance by instance. The only<br>
> solution I can think of is to VNC to the instance, copy the public key to<br>
> my CA server, sign it, and then write the certificate back into the host<br>
> (again via VNC). I cannot ssh without risking a MITM attack. What about<br>
> using Nova user-data? User-data is exposed via the metadata service.<br>
> Metadata is queried via http (reply transmitted in the clear, susceptible<br>
> to snooping), and any compute node can query for any instance's<br>
> meta-data/user-data.<br>
><br>
><br>
><br>
> At this point I have to admit I'm ignorant of details of cloud-init. I know<br>
> cloud-init allows specifying SSH private keys (both for users and for SSH<br>
> service). I have not yet studied how such information is securely injected<br>
> into an instance. I assume it should only be made available via ConfigDrive<br>
> rather than metadata-service (again, that service transmits in the clear).<br>
><br>
><br>
><br>
> What about providing SSH host certificates as a service in OpenStack? Let's<br>
> keep out of scope issues around choosing and storing the CA keys, but the<br>
> CA key is per project. What design supports setting up the SSH host<br>
> certificate automatically for every VM instance?<br>
><br>
><br>
><br>
> I have looked at Vendor Data and I don't see a way to use that, mainly<br>
> because 1) it doesn't take parameters, so you can't pass the public key<br>
> out; and 2) it's queried over http, not https.<br>
><br>
><br>
><br>
> Just as a feasibility argument, one solution would be to modify Nova<br>
> compute instance boot code. Nova compute can securely query a CA service<br>
> asking for a triplet (private key, public key, SSH certificate) for the<br>
> specific hostname. It can then inject the triplet using ConfigDrive. I<br>
> believe this securely gets the private key into the instance.<br>
><br>
><br>
><br>
> I cannot figure out how to get the equivalent functionality without<br>
> modifying Nova compute and the boot process. Every solution I can think of<br>
> risks either exposing the private key or vulnerability to a MITM attack<br>
> during the signing process.<br>
><br>
><br>
><br>
> Your help is appreciated.<br>
><br>
><br>
><br>
> --Pino<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>