X.509 support in ssh (revisited)

[mouring at etoh.eviladmin.org]

As far as I'm aware of there is no such thing as --with-x509 for OpenSSH
unless that article was suppose to come with a patch to OpenSSH.

- Ben

On Wed, 23 Jan 2002, Donald van de Weyer wrote:

> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com
> For additional commands, e-mail: secureshell-help at securityfocus.com
>
>