[13:22] <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:23] <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:24] <harmw> which would be insecure
[13:24] <kwadronaut> true, but snapshot → revert, means we also remove the original one.
[13:29] <harmw> hm, so reverting an instance would endup destroying it and creating a new one?
[13:29] <kwadronaut> let me put it differently
[13:30] <kwadronaut> i have a base image, from which i launch new instances. they always get fresh sshd keys. That's good.
[13:31] <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:32] <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:33] <kwadronaut> Am I making myself more clear?
[13:35] <harmw> yes :)
[13:36] <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:37] <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:38] <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:40] <kwadronaut> yes, but that means getting them off the instances first in the admins computers.
[13:40] <kwadronaut> opening extra attack vectors :-(
[13:41] <harmw> no, instead of having cloud-init generate keys for you, you do that for cloud-init
[13:42] <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:43] <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:45] <kwadronaut> hmhm 
[13:46] <kwadronaut> not entirely happy
[13:50] <harmw> why not :)