An interesting module, but I do not believe I can use it because we use passphrases for our ssh keys. The setup we use is that the individual user controls their private keys while the public keys are collected and distributed to those machines they need to access. I just added a file resource to a user class to fetch the public key when creating the user account.
For rsyslog, the tutorial I am working from is here: http://rsyslog.com/doc/rsyslog_secure_tls.html I was posting a question to a forum for rsyslog and it suddenly occurred to me that I could maybe generate all the certs on the PuppetMaster -- i.e. use the PuppetMaster as a CA for the logging server/client certificates ! To paraphrase Professor Henry Higgins, "By George, I think I have it ! The rain in Spain stays almost invariably in the hills !" On Dec 13, 2011, at 10:06 PM, Phil Frost wrote: > On 12/13/2011 02:40 PM, Daniel Pittman wrote: >> On Tue, Dec 13, 2011 at 05:11, Dan White<y...@comcast.net> wrote: >> >>> I am dealing with SSL certificates for secure rsyslog that need to be >>> created on each machine and then collected onto the logging server. >>> Getting a file from puppetmaster to client is trivial, but how do I reverse >>> the process ? >> >> Can you reverse that, generate the certificates on the master, and >> push them out? There are plenty of tools to hook in on the master >> side to let you do that effectively. > > ssh::auth works something like this, or so I gather. I never actually tried > it: > > http://projects.puppetlabs.com/projects/1/wiki/Module_Ssh_Auth_Patterns > > The problem with doing it this way is it takes the "a" out of "asymmetric > key". Sure, the master could "forget" the private key after it has sent it to > the client, but if the master has been compromised, maybe someone intercepts > it before you delete it. IE, someone can compromise the puppet master or the > client to gain the information needed to impersonate the client. You might as > well just generate a long random key and share it, because it has the same > properties, but is simpler. > > Also, consider that distributing certs with Puppet merely shifts your trust > to the puppet certs. If an attacker gains access to a puppet client's private > key, he can impersonate the puppet client and have the master push the syslog > private key to the attacker's system. Obviously an attacker gaining access to > the puppet master private key is even worse. Since puppet master <-> client > communications are already secured via SSL, perhaps it would be more > convenient to just use those certs. Your master already knows the public keys > of all the clients. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
