nanog mailing list archives

Re: Best practices inquiry: tracking SSH host keys


From: Shumon Huque <shuque () isc upenn edu>
Date: Sun, 9 Jul 2006 22:38:42 -0400


On Sun, Jul 09, 2006 at 04:37:42PM -0400, Steven M. Bellovin wrote:
We already have a deployed key management infrastructure at our 
site (Kerberos). If it were (practically) possible to authenticate 
login sessions to routers with it, we'd definitely use it. I can't 
see us deploying a PKI just to authenticate SSH host keys.

Why not?  PKIs don't have to be big and scary, especially if it's a "pki"
instead of a "PKI".  Assertion: with a few scripts to invoke OpenSSL,
anyone capable of running a Kerberos server is capable of running their
own special-purpose pki for this purpose.

Not fear but operational overhead. I guess I was trying to state
that I already have one key management system, and would like to 
avoid running another one.

But the point is rather moot. SSH implementations on most routers
support neither Kerberos (gss-keyex) nor server authentication with 
certificates, never mind about revocation lists! We could fix that 
by switching to open source routers :-)

Judging from this thread, it appears that some of us are already
using or or planning to use some low tech (and not as automatable) 
method to verify the server's public key. Some of these methods may
qualify as lowercase "pki", depending on your definition.

There is the general chicken-and-egg concern about using network 
based authentication services to access critical network hardware. 
But I think many (most?) of us have other means to access routers 
during catastrophic failures or unavailability of the former. We 
have an out of band ethernet connected to the router consoles, which 
can be dialed into (needs authentication with a hardware token).

But the inband schemes are better, or you wouldn't bother with them. 

Obviously! :-)

--Shumon


Current thread: