authorized_keys2 directory idea

[James Ralston]

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