authorized_keys2 directory idea

[Theo de Raadt]

We have already discussed this at length.

Sorry.

> My $0.02: I'd like to see this feature.
> 
> I'm not really concerned with the authorized_keys{,2} entries.  Where
> I think the feature would be a win is with known_hosts{,2}.  My
> known_hosts file currently has 50+ entries, and it's a royal PITA to
> maintain them.
> 
> The easiest way I've found to reliably keep files in sync across
> different machines is rsync-over-ssh.  That works great if the
> granularity of change you're dealing with is a file, because rsync is
> flexible enough to express conditions like:
> 
>     1.  Only add files that do not exist on the target.
>     2.  Don't overwrite newer files on the target.
>     3.  Delete files that exist on the target but not on the source.
> 
> But when the granularity of change is the *content* of an individual
> file, this won't work.  All I can tell using rsync is that the files
> differ.  To tell what those differences are, I have to scp the remote
> file to the local system, diff it, figure out how to reconcile the
> differences, modify the local version of the remote file, and then scp
> it back to the remote system.
> 
> Now repeat this about a dozen times or so.  It's a big waste of time,
> and it's not fun.
> 
> And yes, this task would be simpler if I could always push my changes
> out immediately after I make them.  But that's not always possible
> (due to firewalls and depending on whether I'm at work, home, or on
> the road).  And it's not always desirable either: my known_hosts files
> are not strictly identical across all of the machines I access.  (I
> could, however, express "push-only-if-older-version-exists-on-target"
> using rsync.)
> 
> On Sun, 3 Jun 2001, Markus Friedl wrote:
> > i don't understand why editing a file is hard.  i think keeping a
> > file in sync is simpler than syncing directories, especially
> > deleting files.
> 
> It might be simpler for you, but that doesn't mean it's simpler for
> everyone.
> 
> On Sun, 3 Jun 2001, Theo de Raadt wrote:
> > OpenSSH is security software.  A lot of you keep asking for more and
> > more features, and the code keeps growing and growing and growing.
> > Assuming that the number of lines per bug is a constant, how long
> > before one of these features which noone uses becomes a hole?
> 
> You have a good point: it would be unwise to carelessly add additional
> features to OpenSSH.
> 
> However, good software grows or dies, and OpenSSH is no exception.
> Carelessly *refusing* to add additional features to OpenSSH will
> damage the project every bit as much (if not more so) than carelessly
> adding additional features, because the former will antagonize more
> people (including supporters and contributors, both current and
> potential) than the latter.
> 
> And in terms of this feature, the complexity added is minimal.
> Processing the subdirectory shouldn't require special pains, because
> it exists in the user's ~/.ssh directory.  If attacker can create
> files or directories in the user's ~/.ssh directory, it's already Game
> Over.
> 
> The effort required by the OpenSSH developers is also negligible,
> because Pekka offered to write the patch.  (Or at least that was my
> interpretation; Pekka, please correct me if I'm placing words in your
> mouth.)
> 
> I realize opinions may have been somewhat polarized by the resulting
> almost-flamefest, but I think Pekka's original suggestion had merit.
> Markus et. al., please [re]consider it.
> 
> -- 
> James Ralston, Information Technology
> Software Engineering Institute
> Carnegie Mellon University, Pittsburgh, PA, USA
>