Re: X.509 and ssh



Richard E. Silverman wrote:
"PG" == Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx> writes:

PG> "JKV" <jkvbe@N O S P A M y a h o o . c o m> writes:
>> Is there any effort going on in standardizing the use of X.509 in
>> ssh?

PG> SSH was specifically designed to not require X.509 (which is one
PG> of the contributing reasons for its runaway success), so you can
PG> forgive the developers for not falling over themselves to
PG> implement it :-).

It is indeed a reason for its early success -- and it is now an impediment
to its adoption in large organizations. The simple known-hosts file
mechanism for server authentication is great for getting SSH up and
running quickly for oneself, or among a small number of hosts. In a
collection of hundreds or thousands of clients and servers, maintaining
these lists becomes an impossible and non-scaling task. Maintaining and
distributing them every time a server is added, removed, or rekeyed
anywhere in the organization is a nightmare. In fact, it may be
practically impossible when you consider that implementations represent
these lists using different formats and mechanisms (e.g. PuTTY uses the
Windows registry), and many clients are simply not available for updating
much of the time (e.g. laptops).

With a standard, distributed trust system such as X.509 PKI, this problem
simply goes away. It is only necessary to distribute to clients, once, a
single root certificate under which server hostkey certificates are
issued. Servers may then be added, removed, or rekeyed at will, with no
client updates needed. Similar improvements are realized if certificates
are also used for user authentication, although that entails much more
overhead and hence is less likely to be necessary or used.

GSSAPI/Kerberos solves the server authentication problem as well, using a
different technology, and solves the hostname aliasing problem too (modulo
security of the DNS). However, it is often not feasible to implement
Kerberos due to practical limitations of today's networks, such as NAT and
firewalls. X.509 is much more self-contained.

Finally, I will note that this definitely is not a theoretical problem. I
am right now in the process of reviewing SSH usage at my company. It is
quite likely that we will go with a commercial implementation rather than
OpenSSH, despite the many advantages of OpenSSH, for precisely this
reason.


Couldn't something be built into the protocol to distribute known_hosts?
For example I connect to server X, it's fingerprint matches the one I
have on file, therefore I trust it and it pushes down a list of all the
hosts it trusts? If there are any new ones, I get them the next time I
connect to the server.

--
To reply by email remove "_nospam"
.



Relevant Pages

  • Re: Mitigate FTP
    ... if you use ssh (server) with scp (in clients) using cryptographic key ... Security Trends Report from Cenzic ...
    (Pen-Test)
  • Re: [SLE] nfs server specification
    ... On Wed, 2004-12-29 at 18:26, steve wrote: ... > Both the nfs and ssh methods work but are too slow. ... LTSP has some docs on their page about server requirements. ... I have run 12 clients on a similar ...
    (SuSE)
  • Re: X.509 and ssh
    ... >> Is there any effort going on in standardizing the use of X.509 in ... PG> SSH was specifically designed to not require X.509 (which is one ... distributing them every time a server is added, removed, or rekeyed ... and many clients are simply not available for updating ...
    (comp.security.ssh)
  • Re: Trouble with X11 over SSH on Mandriva 2010.0
    ... If next clean install/update causes ssh to break, ... installed the sshd daemon/service package (OpenSSH Server) on the server. ... correct values for client and server. ...
    (comp.os.linux.networking)
  • Re: Apache Software Foundation Server compromised, resecured. (fwd)
    ... this was one "result" of the comromised ssh binary at sourceforge. ... a public server of the Apache Software Foundation ... > (ASF) was illegally accessed by unknown crackers. ... > exhaustive audit of all Apache source code and binary distributions ...
    (FreeBSD-Security)