<div dir="ltr"><p style="margin:0in;font-family:Calibri;font-size:11pt">Hi Folks,</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">How to support SSH host certificates in OpenStack?</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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).</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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?</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">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.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">Your help is appreciated.</p><p style="margin:0in;font-family:Calibri;font-size:11pt"> </p><p style="margin:0in;font-family:Calibri;font-size:11pt">--Pino</p></div>