| === jan_ is now known as jtheuer | ||
| jtheuer | I want to sign the newly generated ssh host keys (obviously between key generation and sshd start) -- how could I do that with cloud-init? | 11:26 |
|---|---|---|
| === _crobertsrh is now known as crobertsrh | ||
| smoser | jtheuer, wouldn't you need to have access to the signing private key on the instance ? | 13:18 |
| smoser | natorious, as much as possible, yeah. that would be the case. | 13:19 |
| jtheuer | smoser, yes, I would need the key but fetching it isn't the difficult part. | 13:43 |
| === zz_gondoi is now known as gondoi | ||
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: LICENSE: correct wording with respect to Apache 2 https://review.openstack.org/228471 | 14:06 |
| larsks | Merging: can I specify cloud_final_modules in usedata and have it *merge* with whatever the defaults are in /etc/cloud/cloud.cfg? I think I recall recently talking to smoser about this and the answer was "no", but I forget... | 14:32 |
| smoser | well, you can . but "merge" is sucky for lists by default. | 14:33 |
| smoser | as for lists, merge is just 'replace' | 14:33 |
| smoser | you can manage to prepend or append with cloud-config-jsonp | 14:33 |
| larsks | Actually, I think that may not be true. I found our prior conversation, in which you saidL | 14:34 |
| larsks | <smoser> it appears that you cant patch builtin config | 14:34 |
| larsks | <smoser> you can re-define the whole list though | 14:34 |
| smoser | yeah. | 14:34 |
| smoser | :-( | 14:34 |
| larsks | Yeah. No worries. I knew we had talked about it recently. | 14:34 |
| smoser | probably thats right. i do recall that conversation. | 14:34 |
| smoser | jtheuer, you could probably manage to write a upstart job that would do it. (or systemd job) | 14:35 |
| smoser | and have a bootcommand write the upstart job | 14:35 |
| smoser | have that start on starting sshd | 14:35 |
| smoser | and it could pull your keys (i'm guessing from a https:// do the sign and destroy the keys) | 14:36 |
| smoser | or you coudl have a key signing post service that it could post to that you'd give it one time use url | 14:36 |
| jtheuer | smoser, I currently do it in runcmd but then also needs an ssh restart. But if there is no clean way to do it between key creation and ssh start I'm fine with that. | 14:37 |
| smoser | you should be able to write systemd or upstart jobs that start on starting ssh | 14:37 |
| smoser | and do it there. | 14:37 |
| jtheuer | I would to do it *before* | 14:37 |
| smoser | well, 'starting' is before | 14:37 |
| jtheuer | hmm, didn't know that... ! | 14:38 |
| jtheuer | thanks for the pointer | 14:38 |
| smoser | starting(7) | 14:38 |
| smoser | starting - event signalling that a job is starting | 14:38 |
| smoser | jtheuer, http://manpages.ubuntu.com/manpages/trusty/man7/starting.7.html | 14:39 |
| smoser | that is probably good for upstart, and i'm sure you can find a similar thing in systemd, but i dont know it off the top of my head. | 14:39 |
| smoser | jtheuer, i'm curious how you're acommplishing it, and i'd be open to something to do it in a sane generic way in cloud-init | 14:40 |
| smoser | the other thing you could do is pass the keys into the instance | 14:40 |
| jtheuer | Haven't followed the last war on system init, currently we use ubuntu LTS which uses upstart. I'll check if that is still true for the next LTS version | 14:40 |
| smoser | it will change to systemd in 16.04. Horay for time lost to re-doing things that are already done! | 14:41 |
| smoser | you *can* pass keys into the instance reasonably securely, with #include-once | 14:42 |
| jtheuer | smoser, that would be cool. I see two ways depending on the user's needs: First, add private, public and cert host to cloud-init file. Or second let the instance generate new keys and sign it with a supplied private ca key. (I currently fetch the key from AWS S3 via a script but that is probably not the final version) | 14:42 |
| jtheuer | Then, a line for the host keys certificate has to be added to the sshd config: "HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub" >> /etc/ssh/sshd_config | 14:43 |
| jtheuer | Adding all three files (private, public, cert) to cloud-config.yaml has security advantages, the ca file stays on your local computer. | 14:46 |
| smoser | yeah, but without '#include-once', and a read-once url, you've provided non-root user onthe instance with the ssh private key | 14:47 |
| jtheuer | You mean all users can read the original cloud-init.yaml file? | 14:50 |
| jtheuer | So this is a general issue when you add an ssh private key to cloud-init. Never thought about it... Luckily we only have admins users so far but still not very nice. | 14:53 |
| smoser | jtheuer, well, the user can't read the file on disk | 15:01 |
| smoser | but if it came from an http web service, it is still probably there (ie, on ec2 its in ec2 user-data that is accessible to anyone on that host) | 15:01 |
| jtheuer | Then, I probably didn't get what you mean with your concern about the ssh private key in cloud-init (like it is possible now) | 15:02 |
| jtheuer | or do you refer to the AWS metadata implementation as http endpoint? This is indeed a bit strange that everybody can read the full instance details. | 15:03 |
| === crobertsrh is now known as _crobertsrh | ||
| === gondoi is now known as zz_gondoi | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!