Hi,
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.
