[empty image] [empty image]
[empty image]
[empty image] [empty image] [empty image]
[empty image]

PKIX-SSH
secure shell with
X.509 v3 certificate support


Content:



News:

29 September 2014 : Version x509-8.1
What's new:
  • remove EVP_dss1raw as does not work with OpenSSL 1.0.2 in FIPS mode
    OpenSSL 1.0.2 does not export any more FIPS EVP structures. This impact custom implemenation of EVP_dss1 with signature encoding according SSH norms. In version 8.1 EVP_MD struture dss1raw is replaced with wraper for OpenSSL methods EVP_SignFinal and EVP_VerifyFinal that recode signature according SSH norms.
  • support fipscheck library
    Red Hat-and Red Hat based distribution like CentOS use own FIPS validated OpenSSL implementation and own process for verification if FIPS mode based of fipscheck library.
  • restore arc4random in FIPS mode
    Unfortunately replacement of of RC4 based arc4random* functions in version 7.8 based on OpenSSH 6.5p1 does not follow previous rules. Regression is corrected in this version 8.1 based on OpenSSH 6.5p1.
  • ssh-keysign avoid dependency from "X.509 store" objects
    Now dependencies of ssh-keysign to external libraries are minimized.
  • search know host file by key subtype
    Search for host keys in know host file is enhanced to take into account curve used for EC keys.

11 August 2014 : Version x509-8.0
What's new:
  • Implementation of x509v3-ecdsa-sha2-* keys
    Version 8.0 start to support of x509v3-ecdsa-sha2-* public key algorithms as described in [RFC6187]. You could use configure with --enable-x509v3-ecdsa to enable by default support of those keys.
    For public key algorithms defined in [RFC6187] identity file has to contain X.509 certificate that match private key and chain of certificates leading to a trusted certificate authority.
  • engine and OpenSSL 1.0.1g
    Since OpenSSL version 1.0.1g engines are register internally as result engine support was broken due to attempt to register again. Now pkix-ssh durring engine initialization check whether an engine is registered internally before to request its registration.
  • new distribution model
    Version 8.0 is distributed as complete source package. Authenticity of tar archive could be checked with pgp key <pkixssh-announce@roumenpetrov.info>



Features (valid for latest version) :

  • "x509v3-sign-rsa" and "x509v3-sign-dss" public key algorithms
    X.509 certificates can used as "user identity" and/or "host key" in SSH "Public Key" and "Host-Based" authentications.
    • different "x509v3-sign-rsa" signatures
      As support for MD5 and SHA-1 signature format OpenSSH is interoperable with implementations from multiple vendors. Since "SSH Transport Layer Protocol" internet draft does not specify signature format in case of X.509 certificate for RSA key OpenSSH support both formats.
    • different packing of "x509v3-sign-dss" signature
      As support for DSA signatures packed in format as is described in [RFC2459] and "dss_signature_blob" as is specified in "SecSH transport" draft OpenSSH is interoperable with implementations from multiple vendors. "SSH Transport Layer Protocol" internet draft before version 12 specify "x509v3-sign-dss" public key algorithm to use signature in format is described in [RFC2459], i.e. r and s packed in ASN.1 SEQUENCE. Some vendors pack DSA signature values in "dss_signature_blob" as is specified in "SecSH transport" draft for "ssh-dss" signature.
    • use key and certificate stored in "external devices"
      Implementation require working OpenSSL engine. The identity used in client authentication could refer to external key and/or certificate in format engine:[ENGINE_NAME]:[CERT_CRITERIA], where [ENGINE_NAME] is name of OpenSSL engine and [CERT_CRITERIA] is specific to engine search criteria to find the key and certicate. For instance you could use "friendly name" to access key and certificate stored in "Network Security Services (NSS)" database with e_nss engine from http://developer.berlios.de/projects/enss/. NSS s used in programs(web-browser. e-mail client) like Firefox, SeaMonkey, Thunderbird.
  • verification (default feature)
    By default server(sshd) and clients(ssh,scp,sftp) always verify signatures and validity of certificates in chain when a X.509 certificate is used in authentication. When verification fail that certificate is disallowed. Certificate verification can be disabled when OpenSSH is build without "X.509 store", i.e. configure script is run with --disable-x509store option. In additional client is able to verify remote key using DNS and CERT RR.
  • validation
    • CRL (default feature)
      When a X.509 certificate is used in authentication, server and clients always verify signatures and validity of existing CRLs issued by authorities in certificate chain. Certificate is allowed only when no one of certificates in the chain is revoked. Validation is disabled only when OpenSSH is build without "X.509 store" feature.
    • OCSP (default feature)
      Additional validation is performed when OpenSSH is configured to use OCSP and a X.509 certificate is used in authentication.
  • CERT RR
    ssh can verify host identification using CERT Resource Record published in DNS.
  • OpenSSH Agent (ssh-agent and ssh-add programs)
    Authentication agent can hold X.509 certificates.
  • ssh-keyscan
    This tools can gather "x509v3-sign-rsa" and "x509v3-sign-dss" host keys.
  • ssh-keysign
    This tools used in "Host-Based Authentication" can sign "host keys" containing X.509 certificate.
  • ssh-keygen
    when user identity contain X.509 certificate:
    • create OpenSSH public key and proposed "SECSH Public Key File Format" for that certificate.
    • show fingerprint of certificate.
    • print CERT RR (resource record) for specified hostname.
  • regression tests
    Strong.
  • manual pages
    Detailed.
  • README.x509v3
    Brief description of server and client configuration, regression tests, troubleshooting and FAQ.

Get your version from download pages.



Todo:

  • to implement wildcards(patterns) for DN in "authorized keys" and "known hosts" files;
  • to extend "time limits" with specified time for given revoked certificates.

History:

  1. Initial
    Initial support began from 4 Apr 2002 with version "a". Version "b" issued on 11 Jun 2002 add "X509 store". The store is in use in verification process when a certificate is used as user's identity is ssh session. The store allow use of "distinguished name" in authorized keys file.
  2. Second stage
    In this phase certificate support is implemented in other OpenSSH executables. For first ssh-keygen support certificates since version "c" (20 Jun 2002). This version introduce regression tests. Later in version "d" (30 Jul 2002) support is added to ssh agent.
    As result OpenSSH support certificates as user identity entirely.
  3. Complete support
    Since version "e" (21 Nov 2002) manual pages are updated with information about X.509 certificate support. As well support for certificates as host key in introduced. As version "f" (30 Jan 2003) CRL are supported. Because certificate support is complete as version "f" client prefer algorithms with certificates for host key.
  4. Compatibility
    Compatibility phase begin with version "g" (3 Feb 2003). In version "g1" (30 Apr 2003) regression test scripts are updated to work well with various shells. Since version "g2" (12 Jun 2003) public key algorithm "x509v3-sign-rsa" accept "sha1" signatures in addition to "md5" and now OpenSSH is interoperable with all major ssh implementations. This version work fine with OpenSSL 0.9.7+. Later in versions "g3" (25 Feb 2004) and "g4" (9 Maj 2004) code, documentation and regression test are cleaned up.
  5. Validator
    Fifth phase began with OCSP (Online Certificate Status Protocol) support added in version "h" (6 Apr 2004). Later version schema is changed to more common format with numbers N.N{.N} and next version is 5.1. In version 5.3 compatibility is enhanced to support (in addition to [RFC3279] DSA signatures) format defined for "ssh-dss" signature. Self issued certificates can be pertimed by "autorized keys" file since version 5.4 if configuration allow this. Correction for OCSP responder location obtained from certificate is added in version 5.4 and OCSP SSL support is enabled in 5.5.
  6. International
    Since version 6.0 (7 Aug 2007) openssh can deal with "distinguished name" stored in autorized keys file as UTF-8 string or escaped. Before to compare printable attributes are converted to utf-8.
  7. Integration
    Starting from version 7.0 (22 Aug 2011) openssh can communicate with other applications by using openssl engines. For instance client could use certificates and keys stored in external devices.
    Version 7.1 (15 Jan. 2012) support build with FIPS enabled OpenSSL library and adds direct support of X.509 certificates from PKCS1 module. Since this version sha1 is preferred algorithm and programs start to identify as PKIX in comment from ssh identification string.

News archives:

Miscellaneous:

Recommendet OpenSSL library versions:
Before to use please read:
OpenSSL library versions:
  • 1.0.1
    For use with FIPS enabled OpenSSL 1.0.1 (published on 14 Mart 2012) or later you must download at least version 7.1 of diff.
  • 1.0.0
    For OpenSSL 1.0.0 (published on 29 Mart 2010) or later you must download at least version 6.2.1 of diff.
  • 0.9.8k
    For versions before 0.9.8k see OpenSSL Security Advisory [25 Mart 2009].
    For versions before 0.9.8d see OpenSSL Security Advisory [28 September 2006].
    For versions before 0.9.8c see OpenSSL Security Advisory [5 September 2006].
  • 0.9.7l+security patches (its use is discouraged)
    For versions before 0.9.7l see OpenSSL Security Advisory [28 September 2006].
    For versions before 0.9.7k see OpenSSL Security Advisory [5 September 2006].
    For versions before 0.9.7c see OpenSSL Security Advisory [30 July 2002]
  • 0.9.6k+security patches (its use is discouraged)
    First vulnerability in "ASN.1 Denial of Service Attacks" from OpenSSL Security Advisory [28 September 2006] don't affect 0.9.6 versions but the second one may affect all 0.9.6 versions.
    For all 0.9.6 versions see OpenSSL Security Advisory [5 September 2006].
    For versions before 0.9.6k see OpenSSL Security Advisory [30 July 2002].
    For version 0.9.6i see this mail.
    For versions 0.9.6h+ see X509_NAME_cmp below in document.
  • X509_NAME_cmp
    Method X509_NAME_cmp is changed first in 0.9.7beta4.
    This method remain without modification in betas:0.9.7beta5/6 and in stable 0.9.7+ too.
    Stable OpenSSL versions 0.9.6h+ contain same method.
    Changed method conform with [RFC2459] specification when compare attribute values in PrintableString and IA5String format. This method check type of attributes and when attributes has diffrent types return code is nonzero, i.e. different X509_NAME. O-o-o-p-s-s-s. What happen when one attribute is PrintableString in the first certificate and same attribute is TeletexString in the second? When atribute, as example CN (common name), in a certificate contain as example underscore "_" OpenSSL use type TeletexString but Microsoft Windows implementation treat this incorrectly as PrintableString. Problem is also when a certificate contain atribute as TeletexString "Windows Keystore" convert (!!!!) this attribute to PrintableString. As result client who use that certificate from "Windows Keystore" cannot connect to server using these OpenSSL libraries.

    This method affect all version of "X.509 certificates support in OpenSSH" before version "f". Since version "f" X.509 certificates support in OpenSSH is not affected because contains own method to compare two X509_NAMEs.

[empty image]
[empty image] [empty image] Last modified : Monday September 29, 2014 [empty image]