[01:02] <smoser> vila (who is gone) i've never seen that . that is odd.
[01:29] <smoser> JayF, around ?
[01:34] <smoser> see email
[14:38] <larsks> smoser: my feeling is that the ubuntu ssh packaging is fundamentally broken: there's nothing that will generate new host keys if they are missing when attempting to start sshd.  As far as I can tell, key generation happens only in the package postinst script. I.e., I don't think this is a cloud-init problem.
[14:40] <Odd_Bloke> larsks: I haven't been able to reproduce that issue, so I would tend to agree that it's not cloud-init's problem.
[14:40] <smoser> larsks, you're right, that is the case.
[14:41] <smoser> but it *is* cloud-init's problem here.
[14:41] <Odd_Bloke> Would be good to check with vila precisely what he was doing, in case there's something going on that we don't know about.
[14:41] <smoser> cloud-init needs to generate host keys (even if they exist) on first instance boot.
[14:42] <larsks> smoser: See, I disagree.  I think that maybe cloud-init should have an option to *remove* the keys, but I think that whatever starts sshd should be generating the keys.
[14:42] <smoser> so it is perfectly valid to rm /etc/ssh/ssh_*  in an image and then boot it.
[14:42] <larsks> smoser: Well, right.  That's very common, and that's why I think the ubuntu ssh packaging is so broken.
[14:42] <smoser> wll, that is definitely a path. 
[14:42] <larsks> Because that's a very common situation (removing host keys as part of image prep)
[14:42] <smoser> cjwatson had been averse to that.
[14:43] <smoser> as that would mean the keys (if not present) are created with very little entropy.
[14:43] <smoser> dropbear (often used with busybox) actually generates them on first connect
[14:43] <smoser> which is guaranteed later than daemon start, and thus "better" from a perspective of available entropy.
[14:43] <larsks> That seems like a fine solution, and substantially better than "not generating them at all and being broken" 
[14:44] <smoser> mostly, i've not fought with cjwatson. he's the openssh package maintainer, and very capable :)
[14:44] <larsks> I note that many cloud environments have a mechanism for feeding the entropy pool on virtual instances to help solve the low entropy issue...
[14:48] <smoser> larsks, cloud-init tries to use said entropy also (ie, if it knows of it, it will seed /dev/random with it).
[14:49] <larsks> Okay. So then in many environments low entropy shoulnd't necessarily be a problem.
[14:58] <smoser> larsks, well, except that we have to set cloud-init to correctly run before sshd starts then.
[14:59] <smoser> and also, you can't jsut say "its not a problem in some cloud environments" as any do not have said entropy utils
[15:02] <larsks> cloud-init is going to be generating ssh keys at boot one way or the other, either because the ssh startup script does it or because cloud-init does it natively.  So this is a situation we already have...
[15:05] <larsks> I guess a short-term bug -- that doesn't directly address this issue -- is that the cloud-init systemd unit has a dependency on sshd-keygen.service, which doesn't exist.
[15:05] <Odd_Bloke> cloud-init actually specifies that it should run before sshd-keygen.service.
[15:06] <larsks> Right.
[15:06] <larsks> sshd-keygen.service does not exist (on vivid, at least)
[15:07] <Odd_Bloke> Yeah.
[15:07] <Odd_Bloke> It's pretty much just noise though, so I don't know that it's worth pushing for vivid.
[15:08] <larsks> It is not operationally significant, it's true. 
[21:27] <vila> smoser: \o/
[21:28] <vila> Thanks for the fix, I was trying to write a test and found the right file, now I have the right example ;-D
[21:28] <vila> (https://bugs.launchpad.net/bugs/1445143)