Best practices inquiry: tracking SSH host keys
Steven M. Bellovin
smb at cs.columbia.edu
Thu Jul 6 20:52:52 UTC 2006
On Thu, 29 Jun 2006 19:43:48 +0000 (GMT), "Christopher L. Morrow"
<christopher.morrow at verizonbusiness.com> wrote:
> On Thu, 29 Jun 2006, David W. Hankins wrote:
> > On Wed, Jun 28, 2006 at 06:07:33PM -0700, Allen Parker wrote:
> > > Why not, on a regular basis, use ssh-keyscan and diff or something
> > > similar, to scan your range of hosts that DO have ssh on them (maybe
> > _wow_.
> > That's a massive "why not just" paragraph. I can only imagine how
> > long a paragraph you'd write for finding and removing ex-employee's
> > public keys from all your systems.
> > So, here's my "why not just":
> > Why not just use Kerberos?
> apparently kerberos scares people... I'm not sure I 'get' that, but :( A
> corp security group once for a long time 'didnt believe in kerberos',
> some people 'get it' some don't :(
Kerberos is a single point of failure; that scares people. You *know* you
have to keep the Kerberos server locked down tight, highly available (very
tricky for some ISP scenarios!), etc.
SSH is a distributed single point of failure, just like the old thick
yellow Ethernet. Remember how reliable and easy to debug that was?
More seriously, the original virtue of SSH was that it could be deployed
without centralized infrastructure. That's great for many purposes; it's
exactly what you don't want if you're an ISP managing a lot of servers and
network elements. You really do want a PKI, complete with CRLs. I know
that (most) SSH implementations don't do that -- complain to your vendor.
(Note: the CAs are also single points of failure. However, they can be
kept offline or nearly so, booted from a FooLive CD that logs to a
multi-session CD or via a write-only network port through a tight
firewall, etc. Yes, you have to worry about procedures, physical access,
and people, but you *always* have to worry about those.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
More information about the NANOG