Hi,
I found this a while ago, but didn't have time to look into it. If you do so
maybe you could share your experience ...
In case the mentioned FTP site is down, drop me a mail and I'll send you the
tarball I grabbed.
Donald
----
I found reference to this on the IPSEC mailing list. I think
you might find it useful. Look at
ftp://hplose.hpl.hp.com/pub/nd
Alex
(Yo, Emacs, this is -*- text -*-)
OpenSSH X.509 Extensions
Neil Dunbar (nd at hplb.hpl.hp.com)
January 25th, 2000
1. Introduction
One of the problems with SSH in the larger scale is that key
management becomes quite tricky, as people forget all the accounts
that they have authority to use, and (in an organisation), they leave
without telling the infrastructure staff which keys they had
generated. Add to this that SSH leaves the generation and transport of
private and public keys up to the end user, and the problem can get
quite gruesome.
To this end, I adapted some of the code which I wrote for the
FreeS/WAN project to serve as an interface between SSH and a PKI. Note
that to use these extensions, you will need OpenSSL 0.9.4+ and NOT
SSLeay. The code requires use of the X509v3 extensions, and won't
compile without it. Note: the actual SSH protocol is untouched. Only
the key handling and verification functions have been extended.
2. Configuration
To configure the extensions, add the text '--with-x509' to the
./configure line which you would normally use to configure the OpenSSH
code.
If you want to be able to look up certificates via LDAP, you need to
add '--with-ldap=PATH' to the configure arguments. At the moment, the
code will understand both OpenLDAP and Netscape LDAP SDK 3.0 (although
it doesn't use SSL, for the moment). Thus, assuming that you have the
Netscape SDK in /usr/local/ns-ldap, the configure line might look like
the following -
./configure --prefix=/usr --with-dante --with-x509 \
--with-ldap=/usr/local/ns-ldap
(If you've got OpenLDAP, installed in a sane location like /usr/lib or
/usr/local/lib, then you can generally omit the pathname for LDAP).
After that, compilation and installation should follow by the normal
OpenSSH commands.
3. Usage
The OpenSSH code has been modified such that, in addition to reading
keys from public key files and SSH private key files, it can read
public keys from X.509 certificate files in PEM format, and private
keys either from OpenSSL RSA files, or better still, from PKCS-8 files
(which are defined by reasonably well adhered to standards).
Thus, to generate a key, you can use the sequence of commands as
follows -
openssl req -new -newkey rsa:1024 -nodes -keyout mykey.pem \
-out myreq.pem
[ Followed by requests for the name on the certificate,
country, etc...]
openssl pkcs8 -topk8 -in myreq.pem -out mykey.pk8 (*)
[ Followed by request for the encryption passphrase... ]
rm -f mykey.pem
[ A secure wipe would be preferable to rm -f ...]
(*) if you were generating a host key or unencrypted client key, you
can add the options '-nocrypt' to this stage. Be sure that you really
want an unencrypted key file.
And that's it. Now, once you have your certificate, either signed by
your friendly neighbourhood CA, or self-signed, you should concatenate
the public key certificate to your private key.
cat mycert.pem >> mykey.pk8
This assumes that your certificate is in PEM format. If it's in DER
format, convert it first via -
openssl x509 -inform DER -in mycert.der -outform PEM \
-out mycert.pem
OK. Why do we have to do this step? Answer: because SSH stores its
private/public keypairs as the encrypted private key concatenated to
the unencrypted public key, and loads the public key from the private
key file prior to asking for a passphrase. In a PKCS-8 (or RSA private
key) file, all of the information is encrypted, so that the public key
cannot be loaded from the keyfile without a passphrase. Thus, as a
workaround, we concatenate the (unencrypted) certificate to the end of
the (encrypted) private key, and everything works well.
etc....
----
URL: http://www-unix.gridforum.org/mail_archive/security-wg/msg00050.html