| === harlowja is now known as harlowja_away | ||
| === shardy_afk is now known as shardy | ||
| kwadronaut | probably a more common situation: | 13:22 |
|---|---|---|
| kwadronaut | debian vm (in an openstack environment) gets launched from a base image, generates new sshd keys, so far so good. | 13:22 |
| kwadronaut | but when snapshotting and resetting, it generates new keys again, but shouldn't. | 13:23 |
| kwadronaut | (it gets a new instance-id) | 13:23 |
| harmw | if it wouldn't do that, you'd endup with multiple hosts using the same sshd keys | 13:23 |
| kwadronaut | what'd be the recommended way to deal with that? | 13:23 |
| harmw | which would be insecure | 13:24 |
| kwadronaut | true, but snapshot → revert, means we also remove the original one. | 13:24 |
| harmw | hm, so reverting an instance would endup destroying it and creating a new one? | 13:29 |
| kwadronaut | let me put it differently | 13:29 |
| kwadronaut | i have a base image, from which i launch new instances. they always get fresh sshd keys. That's good. | 13:30 |
| kwadronaut | now, i want to snapshot an instance from some known 'good' state, then I give access to someone so she can play with it, make modifications by hand, make mistakes,... | 13:31 |
| kwadronaut | so we end up with a vm with lots of hand-labor, and want to go back to the first 'good' state. but keeping the sshd_keys. | 13:31 |
| kwadronaut | basically, we boot from the snapshot and destroy the original one. | 13:32 |
| kwadronaut | so yes, that means a new instance-id from openstacks pov, but not from the developers point of view. | 13:32 |
| kwadronaut | Am I making myself more clear? | 13:33 |
| harmw | yes :) | 13:35 |
| kwadronaut | am i making sense? ;-) | 13:36 |
| harmw | hm, so cloudinit should keep its hands off the sshd keys | 13:36 |
| kwadronaut | i could of course purge cloud-init after the first run ;-) | 13:36 |
| harmw | unless it's already capable of doing just that, it shouldn't be that hard to built | 13:37 |
| kwadronaut | but then, there are other modules… | 13:37 |
| harmw | that'll work, ofc :) | 13:37 |
| harmw | for now I'd suggest looking through the docs on cloud-init.cfg | 13:37 |
| harmw | http://cloudinit.readthedocs.org/en/latest/topics/examples.html#configure-instances-ssh-keys | 13:38 |
| harmw | this will force the instance to come up with the specified keys | 13:38 |
| kwadronaut | yes, but that means getting them off the instances first in the admins computers. | 13:40 |
| kwadronaut | opening extra attack vectors :-( | 13:40 |
| harmw | no, instead of having cloud-init generate keys for you, you do that for cloud-init | 13:41 |
| kwadronaut | hmmmmm so you suggest that i do that with user-data on the first run? | 13:42 |
| harmw | eg. cloud-init (or even sshd startupscripts) have logic to run ssh-key-gen (?) which generates the keys found in /etc/ssh/ | 13:42 |
| kwadronaut | correct | 13:42 |
| harmw | yep, cloud-init will see -you- want to have specific sshd keys assigned with this instance and as such it will configure those (instead of generating random keys) | 13:43 |
| kwadronaut | hmhm | 13:45 |
| kwadronaut | not entirely happy | 13:46 |
| harmw | why not :) | 13:50 |
| === harlowja_away is now known as harlowja | ||
| === harlowja is now known as harlowja_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!