I''ve been banging my head on the general problem of
${HOME}/.ssh/authorized_keys distribution (and consequently
.ssh/id_dsa.pub management), especially for automated communication
between servers (think backup systems).
I am aware of various efforts in this direction, all of which are
unsatisfactory:
* there''s a sshkey native type[1] (since 0.24?), but it only manages
/etc/ssh/* keys
* there''s a bunch of recipes on the wiki[2], but they generate all
keys
on the puppetmaster and redistribute it through the ''user''
native
Type, which is not relevant to my setup, for various reasons
* there''s work done in isolation by Micah Anderson[3] and myself[4]
based on those recipes to try to coerce them into making what we
want. I don''t know exactly what Micah did, but my work focused on
integrating the AuthorizedKeysRecipes in DavidS
.. the two last efforts, in my opinion, being a mistake, since they are
both based on centralizing the keys on the puppetmaster, which is really
not flexible enough.
So I''m staring at solution 1, which is the native type, which currently
just manages the stuff in /etc/ssh/* keys. I''m looking for tips on how
to extent and/or replace that type to add the following functionality:
* management of arbitrary "authorized_keys"
(/etc/ssh/ssh_known_hosts,
/home/anarcat/.ssh/authorized_keys...)
* generation of ssh keys (/etc/ssh/ssh_host_[rd]sa_key{,.pub},
/home/anarcat/.ssh/id_[rd]sa{,.pub}
* generation of revocation certificates
From what I can see, right now, the Sshkey type could be extended to the
the first item in there. I *think* we would need a seperate type for the
second and third one, and I think the current type should therefore be
renamed to "ssh_authorized_keys".
Any bright ideas on the path I should follow? I won''t have time to work
on that for the next two weeks, so feel free to take your time to bring
valuable input that would save myself valuable time in my first native
type. :)
Thank you in advance,
A.
[1] http://reductivelabs.com/trac/puppet/wiki/TypeReference#sshkey
[2] http://reductivelabs.com/trac/puppet/wiki/Authorized_keysRecipe
[3] http://mail.madstop.com/pipermail/puppet-users/2008-January/006055.html
[4] awful code yet to be release or never to be released
--
feature, n: a documented bug | bug, n: an undocumented feature
- Mario S F Ferreira <lioux@FreeBSD.org>
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
I''m quite interested in getting involved with this native type. The Anarcat wrote:> So I''m staring at solution 1, which is the native type, which currently > just manages the stuff in /etc/ssh/* keys. I''m looking for tips on how > to extent and/or replace that type to add the following functionality: > > * management of arbitrary "authorized_keys" (/etc/ssh/ssh_known_hosts, > /home/anarcat/.ssh/authorized_keys...)Which syntax were you thinking of ? I have this one in mind. ssh_authorized_key {"useless identifier": ensure => present, type => dsa key => "AAAAB3NzaC...", comment => "francois.deppierraz@camptocamp.com", target => "/root/.ssh/authorized_keys", options => ["command=/bin/blah.sh", "from=1.2.3.4"], } Unfortunately, it seems currently impossible to get rid of the "useless identifier" because puppet types don''t support compound keys[1], right ?> * generation of ssh keys (/etc/ssh/ssh_host_[rd]sa_key{,.pub}, > /home/anarcat/.ssh/id_[rd]sa{,.pub}Yes, you also need a way to bring those public keys back on the puppetmaster to be able to distribute them on other nodes. Exported resources should allow that.> * generation of revocation certificatesI never used that with openssh. For usual authorized_keys, ensure=>absent should be sufficient, no ?> From what I can see, right now, the Sshkey type could be extended to the > the first item in there. I *think* we would need a seperate type for the > second and third one, and I think the current type should therefore be > renamed to "ssh_authorized_keys".The known_hosts and authorized_keys do not share the exact same syntax. IMHO, two different types are required.> Any bright ideas on the path I should follow? I won''t have time to work > on that for the next two weeks, so feel free to take your time to bring > valuable input that would save myself valuable time in my first native > type. :)I''d be interested is looking at the code you already have if any. [1] http://reductivelabs.com/trac/puppet/wiki/ImprovedResourceIdentification --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Agreed this could be arelly useful type. Right now I am figuring out to how to hanlde this using file. The lack of a recursive copy is a bit annoying( Or I am just doing something wrong). On Fri, Mar 28, 2008 at 10:35 AM, Francois Deppierraz <francois@ctrlaltdel.ch> wrote:> > I''m quite interested in getting involved with this native type.> ssh_authorized_key {"useless identifier": > ensure => present, > type => dsa > key => "AAAAB3NzaC...", > comment => "francois.deppierraz@camptocamp.com", > target => "/root/.ssh/authorized_keys", > options => ["command=/bin/blah.sh", "from=1.2.3.4"], > } > > Unfortunately, it seems currently impossible to get rid of the "useless > identifier" because puppet types don''t support compound keys[1], right ? >I do not think the Identifier is useless. It looks like a good way to quickly ID which key goes to which server, should I have to make a manual change somewhere and then change it in puppet. also a good way to require a key be installed before setting up other services. Evan --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Evan Hisey wrote:> I do not think the Identifier is useless. It looks like a good way to > quickly ID which key goes to which server, should I have to make a > manual change somewhere and then change it in puppet. also a good way > to require a key be installed before setting up other services.Yes, but in that case a better identifier would be a compound key derivable from both the key and target attributes. --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> Evan Hisey wrote: > > > I do not think the Identifier is useless. It looks like a good way to > > quickly ID which key goes to which server, should I have to make a > > manual change somewhere and then change it in puppet. also a good way > > to require a key be installed before setting up other services. > > Yes, but in that case a better identifier would be a compound key > derivable from both the key and target attributes. >Not really seeing how a derived compund key is going ot be easier to grep than a human readable name of a server. If I know the server name it is alot faster to grep for that than to figure out a derivable key. I may be missing something, so feel free to enlighten. Evan --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Francois Deppierraz wrote:> I have this one in mind. > > ssh_authorized_key {"useless identifier": > ensure => present, > type => dsa > key => "AAAAB3NzaC...", > comment => "francois.deppierraz@camptocamp.com", > target => "/root/.ssh/authorized_keys", > options => ["command=/bin/blah.sh", "from=1.2.3.4"], > }This is definitely something I''d be interested in, and I just had a quick comment on the syntax here. First, is that you''ll need to specify the user who''s keys you''re adding in. At a minimum, the contents of the .ssh directory need to be owned by that user (as well as has pretty restrictive perms on them), otherwise sshd will ignore them. Once you have the user specified in there somehow, it would be very useful to just specify the home directory of the user, such as with traditional ~username syntax, rather than specifying the full path. This would allow it to work on different machines that keep home directories in different locations, and also let you do a sensible default target value of ''~user/.ssh/''. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Frank Sweetser wrote:> First, is that you''ll need to specify the user who''s keys you''re adding in.IMHO, this user attribute is not required in the native type itself, see below.> At a minimum, the contents of the .ssh directory need to be owned by that user > (as well as has pretty restrictive perms on them), otherwise sshd will ignore > them.Yes, it might be interesting to add those permission checks.> Once you have the user specified in there somehow, it would be very useful to > just specify the home directory of the user, such as with traditional > ~username syntax, rather than specifying the full path. This would allow it > to work on different machines that keep home directories in different > locations, and also let you do a sensible default target value of ''~user/.ssh/''.We could even get rid of the target attribute altogether by adding a user attribute, but this will make the type less generic. What if my sshd looks for authorized keys in /etc/ssh/authorized_keys/%u.pub instead of ~%u/.ssh/authorized_keys, for instance ? What if I want to store those public keys elsewhere because I''m running two different sshd ? I know that my examples may be looking kind of silly but I''m sure that we''ll be better off by keeping the native types the most basic possible. Any other opinion ? You can easily create the type you describe with something like that. Well, except for the user home directory lookup which seems currently unsupported by the file type. define my_ssh_authorized_key($ensure, $key, $user) { ssh_authorized_key{$user: ensure => $ensure, key => $key, target => "/home/${user}/.ssh/authorized_keys", } } Maybe we can even have both a user and a target attributes which are mutually exclusive ? --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Evan Hisey wrote:> Not really seeing how a derived compund key is going ot be easier to > grep than a human readable name of a server. If I know the server name > it is alot faster to grep for that than to figure out a derivable key. > I may be missing something, so feel free to enlighten.No, it won''t be easier to grep, but you won''t need to create some artificial identifier such as "my key on host srv1". You can always put such a comment in the comment attribute. --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Francois Deppierraz wrote:> Frank Sweetser wrote: > >> First, is that you''ll need to specify the user who''s keys you''re adding in. > > IMHO, this user attribute is not required in the native type itself, see > below. > >> At a minimum, the contents of the .ssh directory need to be owned by that user >> (as well as has pretty restrictive perms on them), otherwise sshd will ignore >> them. > > Yes, it might be interesting to add those permission checks. > >> Once you have the user specified in there somehow, it would be very useful to >> just specify the home directory of the user, such as with traditional >> ~username syntax, rather than specifying the full path. This would allow it >> to work on different machines that keep home directories in different >> locations, and also let you do a sensible default target value of ''~user/.ssh/''. > > We could even get rid of the target attribute altogether by adding a > user attribute, but this will make the type less generic. > > What if my sshd looks for authorized keys in > /etc/ssh/authorized_keys/%u.pub instead of ~%u/.ssh/authorized_keys, for > instance ? What if I want to store those public keys elsewhere because > I''m running two different sshd ?I didn''t think about the system wide case, so that''s one where the user might not make sense. As for just sticking it somewhere, I certainly didn''t mean to imply that adding in a user would necessitate removing the target field, merely that it would help in providing a useful default.> I know that my examples may be looking kind of silly but I''m sure that > we''ll be better off by keeping the native types the most basic possible. > Any other opinion ? > > You can easily create the type you describe with something like that. > Well, except for the user home directory lookup which seems currently > unsupported by the file type. > > define my_ssh_authorized_key($ensure, $key, $user) { > ssh_authorized_key{$user: > ensure => $ensure, > key => $key, > target => "/home/${user}/.ssh/authorized_keys", > } > }The problem is that this recipe couldn''t be easily used at the same time on two different hosts, if those hosts each kept user home directories in a different location. I might, for example, want to push the same key out to my linux box in /home/fs/.ssh and an OSX box in /Users/fs/.ssh> Maybe we can even have both a user and a target attributes which are > mutually exclusive ?I don''t think they''d have to be mutually exclusive. Basically, what I was picturing was this: if (user is set) ensure file is owned by that user default target to ~user/.ssh if (target is set) override default target with configured value So you''d end up having to specify at least one of the two, but both would work fine. Does that make more sense? -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2008/3/28, Evan Hisey <ehisey@gmail.com>:> > Agreed this could be arelly useful type. Right now I am figuring out > to how to hanlde this using file. The lack of a recursive copy is a > bit annoying( Or I am just doing something wrong).What is wrong with "recurse => true" on the "file" type? However I didn''t find how to set permissions for the files inside the directory. Creating another "file" for eg .ssh/id_dsa conflicts with File[".ssh"], so I ended up using exec { "chmod 600 .ssh/id_dsa" }. Best regards, -- Jean-Baptiste Quenot http://caraldi.com/jbq/blog/ --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 28 March 2008, Francois Deppierraz wrote:> Evan Hisey wrote: > > Not really seeing how a derived compund key is going ot be easier to > > grep than a human readable name of a server. If I know the server name > > it is alot faster to grep for that than to figure out a derivable key. > > I may be missing something, so feel free to enlighten. > > No, it won''t be easier to grep, but you won''t need to create some > artificial identifier such as "my key on host srv1". You can always put > such a comment in the comment attribute.Which is why I believe that with this syntax, the "comment" field is superfluous. Writing the comment into the namevar will also make the implementation much easier (see ParsedFile and friends). Regards, DavidS - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH7oKo/Pp1N6Uzh0URAvM/AJ9Lbk6aRunGXEjY1n7sSZM/PEehPgCfZX1z TF7QdbNudL002rDYA90oPxo=RnEu -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Jean-> > Agreed this could be arelly useful type. Right now I am figuring out > > to how to hanlde this using file. The lack of a recursive copy is a > > bit annoying( Or I am just doing something wrong). > > What is wrong with "recurse => true" on the "file" type? > > However I didn''t find how to set permissions for the files inside the > directory. Creating another "file" for eg .ssh/id_dsa conflicts with > File[".ssh"], so I ended up using exec { "chmod 600 .ssh/id_dsa" }.I was doing something wrong it seems, recurse was a bit vague for me as to what it really did. I was setting the ensure wrong which was given me an erro I was not groking. Evan --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
David Schmitt wrote:> Which is why I believe that with this syntax, the "comment" field is > superfluous. Writing the comment into the namevar will also make the > implementation much easier (see ParsedFile and friends).That''s a good point. --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---