Best practices inquiry: tracking SSH host keys

Fri Jul 7 14:18:35 UTC 2006

--On Thursday, July 06, 2006 18:22:48 -0700 Jeremy Chadwick 
<nanog at jdc.parodius.com> wrote:

> Speaking purely from a system administration point of view, Kerberos
> is also a nightmare.  Not only does the single-point-of-failure
> induce red flags in most SAs I know (myself included),

If a deployed kerberos environment has a single point of failure then its 
been deployed poorly.  Kerberos has replication mechanisms to provide 
redundancy.  The only think you can't replicate in K5 is the actual master, 
meaning that if the master is down you can't change passwords, create 
users, etc.  While thats a single point of failure its not typically a 
real-time critical one.

> but having
> to "kerberise" every authentication-oriented binary on the system
> that you have is also a total nightmare.

As you pointed out, one trivial rebuttal to that is PAM, another is GSSAPI 
and SASL.  Authentication oriented systems shouldn't be hard coding a 
single auth method these days, they should be using an abstraction layer 
GSSAPI or SASL.  If they are then the GSSAPI Kerberos auth mechanisms 
should just work.  GSSAPI/SASL enabled versions of many major applications 
are available (Thunderbird, Mail.app, openssh, putty, oracle calendar). 
(Sadly Microsoft applications are fairly lacking in this category, which is 
surprising considering that AD servers use Kerberos heavily under the hood.)

> Kerberos 4 is also
> completely incompatible with 5.

Not true.  With a correctly setup environment K5 tickets can be used to get 
K4 ticket automatically for those few legacy applications that require K4. 
But really there are very few K4 only applications left.

>Let's also not bring up the issue
> of globally-readable Kerberos tickets laying around /tmp on
> machines which use Kerberos, okay?  ;-)

Again, thats an indicator of a poorly setup system.  Ticket files should be 
readable only by the user.  If they're readable by anyone else except root 
something isn't setup right.  And on OS'es that support it the tickets are 
often stored in a more protected location.  i.e. on OSX the tickets are 
stored in a memory-based credential cache.

> The bottom line is that SSH is "easier", so more people will use
> it.  That may not be the best attitude, I'll admit, but that's
> reality.
>

I think the bottom line for the original poster was that ssh was the only 
secure mechanism support by the devices he was using.  For network switches 
this is common.  I think the only answer there is to either make gathering 
the ssh key from the device part of your build/deployment process, or 
design your network in a way that reduces the opportunity for 
man-in-the-middle ssh key exchange attacks and pray.

-David