smoservila (who is gone) i've never seen that . that is odd.01:02
smoserJayF, around ?01:29
smosersee email01:34
=== harlowja is now known as harlowja_away
=== rangerpbzzzz is now known as rangerpb
larskssmoser: 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:38
Odd_Blokelarsks: 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
smoserlarsks, you're right, that is the case.14:40
smoserbut it *is* cloud-init's problem here.14:41
Odd_BlokeWould 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
smosercloud-init needs to generate host keys (even if they exist) on first instance boot.14:41
larskssmoser: 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
smoserso it is perfectly valid to rm /etc/ssh/ssh_*  in an image and then boot it.14:42
larskssmoser: Well, right.  That's very common, and that's why I think the ubuntu ssh packaging is so broken.14:42
smoserwll, that is definitely a path. 14:42
larsksBecause that's a very common situation (removing host keys as part of image prep)14:42
smosercjwatson had been averse to that.14:42
smoseras that would mean the keys (if not present) are created with very little entropy.14:43
smoserdropbear (often used with busybox) actually generates them on first connect14:43
smoserwhich is guaranteed later than daemon start, and thus "better" from a perspective of available entropy.14:43
larsksThat seems like a fine solution, and substantially better than "not generating them at all and being broken" 14:43
smosermostly, i've not fought with cjwatson. he's the openssh package maintainer, and very capable :)14:44
larsksI note that many cloud environments have a mechanism for feeding the entropy pool on virtual instances to help solve the low entropy issue...14:44
smoserlarsks, cloud-init tries to use said entropy also (ie, if it knows of it, it will seed /dev/random with it).14:48
larsksOkay. So then in many environments low entropy shoulnd't necessarily be a problem.14:49
smoserlarsks, well, except that we have to set cloud-init to correctly run before sshd starts then.14:58
smoserand also, you can't jsut say "its not a problem in some cloud environments" as any do not have said entropy utils14:59
larskscloud-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:02
larsksI 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_Blokecloud-init actually specifies that it should run before sshd-keygen.service.15:05
larskssshd-keygen.service does not exist (on vivid, at least)15:06
Odd_BlokeIt's pretty much just noise though, so I don't know that it's worth pushing for vivid.15:07
larsksIt is not operationally significant, it's true. 15:08
=== harlowja_away is now known as harlowja
=== rangerpb is now known as rangerpbzzzz
=== harlowja is now known as harlowja_away
vilasmoser: \o/21:27
vilaThanks for the fix, I was trying to write a test and found the right file, now I have the right example ;-D21:28
=== harlowja_away is now known as harlowja
=== [1]claudiupopa is now known as claudiupopa

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!