OpenSSH Certkey (PKI)
andre at freebsd.org
Thu Nov 16 01:52:20 EST 2006
Daniel Hartmeier wrote:
> This patch against OpenBSD -current adds a simple form of PKI to
> OpenSSH. We'll be using it at work. See README.certkey (the first chunk
> of the patch) for details.
> Everything below is BSD licensed, sponsored by Allamanda Networks AG.
As the one who assigned this work to Daniel Hartmeier I can add the
rationale for this simple and easy PKI functionality in OpenSSH.
Rationale for PKI in OpenSSH:
Managing a large m:n relationship of users and hosts in OpenSSH is
tedious and requires the use of scripting and rsync distribution
methods for known_hosts and authorized_keys with all associated
Users tend not to verify server pubkey fingerprints out of band
upon the first connection attempt which weakens the strong theoretic
security of SSHs public key system.
Known_hosts and authorized_keys do not contain any validity or
expiration information. Reality shows that a lot of cruft and
old information tends to remain. This tends to accidentally
leave once granted privileges to users or hosts which should no
longer posses them. It requires strict discipline to properly
clean up and stay up to date on n hosts.
What does OpenSSH PKI do:
It does three things:
a) It adds a certificate to the public key of a ssh server so the
ssh client can verify the authenticity of a server pubkey without
having to rely on other unspecified out of band methods (on first
connection) or the known_hosts file (on subsequent connections).
b) It adds a certificate to the public key of a ssh user so the ssh
server can verify the authenticity of a users pubkey without having
to have a pre-populated authorized_keys file in each users home
directory on all machines this user has access to.
c) It adds a number of optional fields in the certificate which can
specify additional constrains on the hosts and users. The constrains
include lists of IP addresses or networks which limit where the clients
or server can connect to/from. This way hosts with a number of interfaces
can be handled as one entity. Moving/copying of server pub/privkeys to
a different IP address is prevented. Users may be restricted to be
able to login only from defined list of IP addresses/networks specified
in the certificate.
What are the advantages:
Only the CA's public key has to be distributed once to all hosts.
-> Can be rolled into the host setup procedure/automation.
The CA has to sign each host or user public key once.
None of the user or host keys have to be distributed (copied) to
all other hosts.
-> Instant acceptance by all hosts with the same CA pubkey.
The addition of any users or hosts is controlled by the CA.
-> Single point of entry and control.
The CA specifies the expiry date of any user and host certificate
thus a policy can regularly timeout any of them.
-> Any old cruft and temporary privileges expire by itself w/o
having to individually check all hosts for them.
Who is it for:
Centrally managed organizations or collections of hosts which trust
a single master role (the CA certification authority, a.k.a 'root').
Many real world deployments do resemble the single trust model of
What are the risks:
All trust and authentication/authorization is vested in the operator
of the CA and the strength and secrecy of the CA private key. If the
CA operator or the CA private key are compromised all doors are open.
The CA operator is equal to 'root' which is trusted anyway. He can do
everything root can do (that is reading/modifying each users private
keys and authorized keys files).
Less severe incidents include lost or compromised user keys. OpenSSH
PKI gives two methods to deal with this. First it allows to specify
an expiry date for all certificates. If set sufficiently short all
certs lose their usefulness quickly. All users have to be re-certified
in intervals and the re-certification can be tied to any number of
administrative criteria. For immediate reactions any number of public
key fingerprints can be blacklisted on the ssh server. This is a simple
file based certificate revocation. Online revocation checks could
optionally be implemented as well. The operator then has to specify
whether to fail open or close depending on priorities and risk
Why not implement/use X.509 or OpenPGP PKI methods:
The goal is to use only basic and non-complex cryptographic methods
which are widely available and do *not* require the installation of
additional software libraries (eg. OpenPGP SDK or OpenSSL for OpenBSD)
and a simple and modular certificate binary format (no ASN.1 or such).
It should work out of the box on all currently supported OpenSSH
platforms without any external dependencies.
This OpenSSH PKI system is very simple and easy to use. All programs
and functions necessary to use it to its full extent are included with
the base OpenSSH distribution.
More information about the openssh-unix-dev