[01:02] vila (who is gone) i've never seen that . that is odd. [01:29] JayF, around ? [01:34] see email === harlowja is now known as harlowja_away === rangerpbzzzz is now known as rangerpb [14:38] 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] 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] larsks, you're right, that is the case. [14:41] but it *is* cloud-init's problem here. [14:41] 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] cloud-init needs to generate host keys (even if they exist) on first instance boot. [14:42] 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] so it is perfectly valid to rm /etc/ssh/ssh_* in an image and then boot it. [14:42] smoser: Well, right. That's very common, and that's why I think the ubuntu ssh packaging is so broken. [14:42] wll, that is definitely a path. [14:42] Because that's a very common situation (removing host keys as part of image prep) [14:42] cjwatson had been averse to that. [14:43] as that would mean the keys (if not present) are created with very little entropy. [14:43] dropbear (often used with busybox) actually generates them on first connect [14:43] which is guaranteed later than daemon start, and thus "better" from a perspective of available entropy. [14:43] That seems like a fine solution, and substantially better than "not generating them at all and being broken" [14:44] mostly, i've not fought with cjwatson. he's the openssh package maintainer, and very capable :) [14:44] 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] larsks, cloud-init tries to use said entropy also (ie, if it knows of it, it will seed /dev/random with it). [14:49] Okay. So then in many environments low entropy shoulnd't necessarily be a problem. [14:58] larsks, well, except that we have to set cloud-init to correctly run before sshd starts then. [14:59] 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] 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] 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] cloud-init actually specifies that it should run before sshd-keygen.service. [15:06] Right. [15:06] sshd-keygen.service does not exist (on vivid, at least) [15:07] Yeah. [15:07] It's pretty much just noise though, so I don't know that it's worth pushing for vivid. [15:08] It is not operationally significant, it's true. === harlowja_away is now known as harlowja === rangerpb is now known as rangerpbzzzz === harlowja is now known as harlowja_away [21:27] smoser: \o/ [21:28] 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] (https://bugs.launchpad.net/bugs/1445143) === harlowja_away is now known as harlowja === [1]claudiupopa is now known as claudiupopa