I agree with much of what Felix said here. Most importantly, John's "every possible file everywhere" is more than a bit extreme. (sorry, John :D ) I actually think that something even more limited than what Felix suggested would solve most desires. I believe that purging unlisted SSH keys for all users puppet is explicitly set to manage would solve 90% if not much more of the problem.
In essence, manage SSH keys for users which Puppet has defined. This fits cleanly within the Puppet model and doesn't cause unexpected behavior. This is a perfectly reasonable target and would solve most complaints. People who want all users to have their SSH keys purged would put all users in their manifests :D On Nov 21, 2013, at 12:39 PM, Felix Frank <[email protected]> wrote: > I'm forking this thread from a cron discussion on the development list. > I feel that the exchange of design ideas regarding the much requested > cleaning of authorized ssh public keys is of interest to the base of > (potential) users and is not (yet) closely related to implementation > details. > > On 11/21/2013 09:10 PM, John Bollinger wrote: >> >> There is a similar request for ssh_authorized_keys, which is >> just about >> at the top of the highly voted issues (see [2]). >> >> >> >> There are indeed similarities here with Ssh_authorized_key, but also >> some important differences. Consider that Ssh_authorized_key can >> manage any file as a keystore (see the 'target' parameter). As such, >> it is flatly impossible for Puppet to reliably determine from which >> files it must purge keys to zap them all without collateral damage. >> Puppet could be conservative by only purging from files having the >> standard name, but if Ssh_authorized_key.target has any use in the >> first place then a conservative purge would miss some keys in some >> environments. I think it would be worse to provide a key purging >> feature that doesn't do the full job than to omit key purging altogether. > > I think we can agree that "clearing all public keys from all files" is > out of the question. It cannot and should not be the goal in my opinion. > > For the vast majority of users, it will be important that the "active" > keys are accounted for, i.e. such keys that are installed in > authorized_keys files which will be read by an sshd to find trusted > public keys. > > Taking this perspective, using the default location would be a fair > start indeed. I can think of two ways of extending that approach. > > 1. Try to locate and interpret the system-wide sshd configuration. Find > the actual location(s) used for authorized keys files. > > 2. Add a parameter (to the resources type?) that allows to override the > default location of a user's authorized keys file. Think resources { > "ssh_authorized_key": purge => true, location => "%h/.ssh_hidden/keys" }. > > Both approaches could also be combined, of course. > > There will always be limitations, e.g. we cannot protect the admin from > users (or other admins) running additional sshd instances with different > configurations. But doing so would be well beyond the scope of what I, > as a user, would expect from puppet. > >> I think a more feasible reference model for key purging is the one >> provided by recursively-managed Files. Essentially, there is a >> container (a File resource) that establishes the scope of the purge. >> There is not currently a suitable container type for authorized keys, >> but one could certainly be created, say Ssh_authorized_keyfile or >> Ssh_authorized_keys. > > I can see how this would be more in the spirit of puppet design than > what I sketched above. But wouldn't this require the manifest designer > to enumerate all key files after all? > > That's quite a limitation, because usually (see user, group) purging > resources is expected to act specifically upon resources that are not > covered by the manifest at all. > > I can see scenarios where such a feature would be useful, e.g. in a > defined type that manages all aspect of a user account, their authorized > keys file could be added to the list. However, if the manifest design > allows for such convenience, it will also easily allow workarounds such > as handling the key files via the concat module or just adding a dummy > for each user in order to allow the current purging mechanism to apply. > This makes me question the value of such a container type. > > Best regards, > Felix > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/528E6F92.6050601%40Alumni.TU-Berlin.de. > For more options, visit https://groups.google.com/groups/opt_out. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. Author of Instant Puppet 3 Starter: http://www.netconsonance.com/instant-puppet-3-starter-book/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/87829A4B-D4CB-43CF-B955-2527D972688C%40netconsonance.com. For more options, visit https://groups.google.com/groups/opt_out.
