Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.security.ssh > #118

Re: known_hosts file on trusted server

From res@qoxp.net (Richard E. Silverman)
Newsgroups comp.security.ssh
Subject Re: known_hosts file on trusted server
References <39b664e9-f8a2-45c2-8427-56eae1b2e25d@c1g2000yqe.googlegroups.com> <9ee4573f-e661-477a-917f-4091f1d84168@gc3g2000vbb.googlegroups.com>
Message-ID <m2liwv1u18.fsf@darwin.oankali.net> (permalink)
Organization Thundernews
Date 2011-06-21 04:13 -0400

Show all headers | View raw


Nico Kadel-Garcia <nkadel@gmail.com> writes:

> SSH keys are useful, but their reliability for identifying hosts
> is..... not thought out end-to-end. There is no good mechanism for
> expiring and replacing the host keys in an authenticated fashion,
> there is no central signature authority or chain of trust to establish
> them as there are for SSL and PGP keys, and people are far too willing
> to accept the keys of unknown hosts. This actually represents a very
> real attack vector for man-in-the-middle attacks, and a monitoring
> technology for some of the more sophisticated network tools to monitor
> all your traffic. SSH is very powerful and effective for protecting
> the traffic from casual monitoring, but it's not currently that
> effective for authenticating the actual server, itself. Without robust
> protection of the host keys on the server, and without reliable
> authentication of those keys, it's not effective against governments
> willing to subpoena, or steal, hostkeys and set themselves up for man-
> in-the-middle.

Hi Nico,

There's an important point to be made here: everywhere in your
discussion, you sould replace "SSH" with "OpenSSH."  The problems you're
discussing are limitations of the OpenSSH software, not SSH as a
protocol.  There are several commercial implementations which support
robust, manageable, scalable methods of server authentication.  Both
Tectia and VanDyke have Unix SSH servers which implement both X.509
certificate and Kerberos key exchange mechanisms, and have done so for a
long time.  By comparison, although OpenSSH has had Kerberos *client*
authentication for some time, the OpenSSH project has for ages refused
to integrate Simon Wilkinson's excellent patches for GSSAPI key exchange
-- though this lack is mitigated by the fact that the major Unix players
*do* integrate his work into their distributions, so this feature is in
fact widely available.  It's a shame more people aren't comfortable
deploying Kerberos; it provides effortless single-signon and server
authentication, and across many more platforms and technologies than
just SSH (I've been working a great deal with Kerberos over the past few
years).

Failing Kerberos, the OpenSSH folks have recently gotten around to
providing server public-key certificates -- but, they decided to
completely eschew standards, inventing their own certificate format and
system rather than using X.509.  This ensures that, even if you've
already deployed a PKI, you can't leverage that work.

The whole point of Kerberos and PKI is to build it once, addressing the
distributed trust and authentication problem in an overall fashion, and
then get everything you possibly can to use it.  OpenSSH ignores both
technologies, pretty much the only games in town these days.  It's an
odd set of choices.

- Richard

Back to comp.security.ssh | Previous | NextPrevious in thread | Find similar


Thread

known_hosts file on trusted server goodnite <david.tolo@gmail.com> - 2011-05-26 10:33 -0700
  Re: known_hosts file on trusted server Nico Kadel-Garcia <nkadel@gmail.com> - 2011-06-11 19:42 -0700
    Re: known_hosts file on trusted server res@qoxp.net (Richard E. Silverman) - 2011-06-21 04:13 -0400

csiph-web