authorized_keys2 directory idea

[James Ralston]

On Sat, 9 Jun 2001, Gert Doering wrote:
> Now for known_hosts, I tend to disagree - I don't see any compelling
> reason to exclude hosts from that list.

An individual user's known_hosts file is implicitly prefixed with the
following comment:

    #
    # Hi there, system cracker!  This is my known_hosts file.  This
    # file lists all the machines I connect to on a regular basis.
    # So, if you've broken into this machine and are reading this
    # file, do yourself a favor, and target these machines first.
    # Granted, if you're good, you'll figure this out anyway, but why
    # waste the effort when I've conveniently collected all this
    # information right here for you?  An IDS might be on your tail
    # already, so you better get cracking (no pun intended).
    #

Even worse is the case of maintaining the same known_hosts file on
both sides of a firewall.  If the DNS for the domain is configured to
not return information about internal hosts to external requestors
(which is often a reasonable thing to do), then by dragging
information about external hosts outside the firewall, you've given a
potential attacker information that might otherwise be quite difficult
to gather.  (This is particularly true if you use "CheckHostIP yes",
which is OpenSSH's default unless explicitly overriden--if that's the
case, not only have you revealed the names of internal hosts to a
potential attacker, but you've revealed their IP addresses as well.)

Gert continued:
> So what we do is just "collect all host keys on one central machine,
> and distribute the complete file from there".

I wish I were in your shoes--that all of my access patterns involved
one tidy centralized domain, and that I could just rely on a single
global known_hosts file.  But the world is not an ideal place, and my
particular world is nowhere near that simple.

My activities involve multiple machines across multiple domains.
However, due to geographical locations and firewalls, it is *not* the
case that I need to be able to login from every single machine to
every other machine.  The actual access patterns I require are quite
small.  Therefore, the contents of my known_hosts files is a minimal
set for each machine.  That way, if one of the boxes I use were to be
cracked, I've reduced the information that the attacker would start
with.  The additional time this would buy might be the difference
between intercepting and isolating the attack, and having the attacker
successfully continue the attack through to other hosts.

Gert continued:
> With the keys, it's not that easy, as not everybody has access
> everywhere.

Replace "keys" with "known_hosts", and I'd wager your statement is
still true for many people.  (As I've illustrated, it's certainly
still true for me.)

On Sat, 9 Jun 2001, Markus Friedl wrote:
> for known_hosts you have to scan your net and build a single file of
> trusted hosts that can be distributed to all client machines.

One doesn't "have to" do anything of the sort.  I don't maintain my
personal known_hosts file that way, as I've illustrated above.  (Even
if I *wanted* to do it that way, I couldn't; I have hosts from
multiple different domains in my known_hosts file.)

Markus continued:
> you have to check this file for key changes.
> checking for new files is much harder than
>         $ diff a b

You're assuming that all users of OpenSSH have a single known_hosts
file that is byte-for-byte identical to a single global collected host
keys files for a single domain.  This assumption is false.

Let's say that I have 3 sets of collected host keys, each set
containing hosts from a separate and unique domain.  Let's call these
sets {a}, {b}, and {c}.  My personal known_hosts file is set {k},
where {k} is a subset of the union of {a}, {b}, and {c}, and the
intersections of {k} with each of {a}, {b}, and {c} are all non-empty
sets.

In the above scnenario, you cannot check for key changes by using a
diff command.

If the host keys were stored as single files, you could easily check
for key changes by using rsync with the --existing option.

Or, using a hybrid solution, if OpenSSH's algorithm would be to look
for multiple keys in each file, and to continue seaching until it
either found a matching key or exhausted all files, you could create
multiple files for each domain:

    ~/.ssh/known_hosts/foo.com
    ~/.ssh/known_hosts/bar.com
    ~/.ssh/known_hosts/podunk.edu

Then, assuming you weren't maintaining subsets of each domain's global
host keys files, you *could* actually use individual "diff" commands
to check for changes...

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA