Multiple user keys per slice on VM boot.

[llpeterson]

Multiple user keys per slice on VM boot.

[andybavier]

Tony suggested that we use the "--file" argument to the "nova boot" command for this, if that is working in our current infrastructure. It worked with Essex but gave us problems on Folsom.

[andybavier]

We could break this into two problems:

(1) Getting multiple SSH keys into the VM
(2) Copying the SSH keys from inside the VM to set up the proxy login account

For (1) there are a number of ways we could proceed, but probably the cleanest is to use cloud-init. To add multiple keys we would supply a user-data script:

#cloud-config
ssh_authorized_keys:
  - ssh-rsa AAAAB3NzaC1...
  - ssh-rsa AAAAB3NzaC1...

... etc.

For (2) we could use guestfish. Here is a command that copies out all of the SSH authorized keys in all of the user accounts in the VM 'instance-00000034':

$ guestfish --ro -d instance-00000034 -i glob cat /home/*/.ssh/authorized_keys

Since we don't know when keys inside the VM have been added or changed, we'd probably want to run this command in a cron job every few minutes for every VM. It appears to take about 5 seconds per VM to complete.

Some advantages to doing it this way:

• Requires very little code/setup - just a cron job on the nodes, and a script to generate the user-data
• Lets us get rid of a hack to nova-compute where we intercept the key so that we can set up the proxy login account

[scottmbaker]

The user-data you're creating for cloud-init is in YAML format? If so, then
it should be straightforward to add this to sync_slivers.py:get_userdata().

My only concern is copying out all of the keys in all of the user accounts
inside the VM. I would be worried about VMs creating account names that
conflict, either unintentionally or intentionally (as some sort of spoofing
or DOS attempt).

I would also anticipate some leakage of nuisance accounts that weren't
intended to be reachable via the NAT interface. For example, the log
aggregation server had an account that was used by HPC nodes to deposit
their logs via rsync over SSH. In an XOS world, that could have been
implemented via a private network between HPC and the log server. (we're
not setting up the log server on XOS, so it's a moot point, just an example
of potential configuration)

Scott

On Thu, Mar 12, 2015 at 8:24 AM, Andy Bavier [email protected]
wrote:

We could break this into two problems:

(1) Getting multiple SSH keys into the VM
(2) Copying the SSH keys from inside the VM to set up the proxy login
account

For (1) there are a number of ways we could proceed, but probably the
cleanest is to use cloud-init. To add multiple keys we would supply a
user-data script:

#cloud-config
ssh_authorized_keys:

• ssh-rsa AAAAB3NzaC1...
• ssh-rsa AAAAB3NzaC1...

... etc.

For (2) we could use guestfish. Here is a command that copies out all of
the SSH authorized keys in all of the user accounts in the VM
'instance-00000034':

$ guestfish --ro -d instance-00000034 -i glob cat
/home/*/.ssh/authorized_keys

Since we don't know when keys inside the VM have been added or changed,
we'd probably want to run this command in a cron job every few minutes for
every VM. It appears to take about 5 seconds per VM to complete.

Some advantages to doing it this way:

• Requires very little code/setup - just a cron job on the nodes, and
  a script to generate the user-data
• Lets us get rid of a hack to nova-compute where we intercept the key
  so that we can set up the proxy login account

—
Reply to this email directly or view it on GitHub
#3 (comment).

[andybavier]

We could stick with copying out keys in the default user accounts (e.g., ubuntu). This is easy right now since the only images we support are Ubuntu images.

[scottmbaker]

That sounds like a plan. Even in the Centos-5.5 image, I named the default
user 'ubuntu'.

Scott

On Thu, Mar 12, 2015 at 12:27 PM, Andy Bavier [email protected]
wrote:

We could stick with copying out keys in the default user accounts (e.g.,
ubuntu). This is easy right now since the only images we support are Ubuntu
images.

—
Reply to this email directly or view it on GitHub
#3 (comment).