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

secure shell with
X.509 v3 certificate support



18 Mart 2015 : Version x509-8.3
What's new:
  • Version 8.3 includes OpenSSH 6.8p1
    Continue refactoring of key-related functions to be more library-like.
    Minimum supported OpenSSL version is 0.9.7.
  • pattern in allowed algorithms
    Version 5.4 published on 24 November 2004 (for more details see news archives), implement for first time new server options PubkeyAlgorithms and HostbasedAlgorithms to restrict allowed protocol version 2 algorithms in public-key or host-based authentication. Also PubkeyAlgorithms is available in client. With version 8.2 format is changed to accept wildcard pattern with default value *, i.e. allowed all algorithms. Note that wildcard pattern format is backward compatible with previous lists.
    For consistency version 8.2 adds new client option - HostbasedAlgorithms. The default value of client options is *, i.e. allowed all algorithms. Both client options also support pattern matching.
  • OpenSSL engine support
    With code refactoring of key-related functions to be more library-like in version 8.2 broke engine support. Now code of engine related functions is refactored and support is restored.
  • Portability
    This version adds some portability improvements for born shell scripts used in regression tests.

23 November 2014 : Version x509-8.2
What's new:
  • Version 8.2 includes OpenSSH 6.7p1
    OpenSSH 6.7p1 refactor key-related functions to be more library-like.
    Also OpenSSH 6.7p1 drop TCP-wrappers and adds requires at lest OpenSSL 0.9.8f to build.
  • Minimum OpenSSL version - 0.9.7
    PKIX-SSH drop support for OpenSSL 0.9.6. It continue to support OpenSSL 0.9.7 and all 0.9.8 with wrapper functions for missing or buggy functionality. Note that engine functionality in OpenSSL 0.9.7 is not so stable and in some host configurations load of OpenSSL engines may fail.
  • TCP-wrappers support
    PKIX-SSH continue to support TCP-wrappers.
  • Support ECDSA X.509 keys in agent
    Unfortunately version 8.1 was released without support in agent. Version 8.2 correct this mistake.
  • Portability fixes
    Correction is in regression tests to use more portable command invocation.
    Also detection of "unix" netcat in multiplex tests is improved. Now tests pass on solaris.
    Note that netcat commands used in linux distributions does not fulfill yet requirement of multiplex regression test.
  • How to build with FIPS enabled OpenSSL on Solaris 11
    PKIX-SSH pass all test on Solaris 11 using FIPS enabled OpenSSL with following configuration:
    CONFIG_SHELL=/bin/ksh \
    CC='gcc -m64' \
    CPPFLAGS='-I/usr/include/openldap -I/usr/include/openssl/fips-140' \
    .../configure \
    --enable-ldap --with-ldap-libs='-lldap-2.4 -llber-2.4' --with-ldap-libexecdir=/usr/lib \
    --enable-openssl-fips \
    --enable-x509v3-ecdsa ...
    Note that compiler flag -m64 is required for build with FIPS enabled OpenSSL library.

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) :

  • public key algorithms:
    • x509v3-sign-rsa
    • x509v3-sign-dss
    • x509v3-ecdsa-sha2-nistp256
    • x509v3-ecdsa-sha2-nistp384
    • x509v3-ecdsa-sha2-nistp521
    RSA, DSA or ECDSA X.509 certificates could be used as "user identity" and/or "host key" in SSH "Public Key" and "Host-Based" authentications.
    • different "x509v3-sign-rsa" signatures
      As support for SHA-1 and MD5 signature format PKIX-SSH is interoperable with implementations from multiple vendors. Both formats are supported because "SSH Transport Layer Protocol" internet drafts does not specify signature format in case of X.509 certificate for RSA key.
    • different packing of "x509v3-sign-dss" signature
      PKIX-SSH is interoperable with implementations from multiple vendors. It support DSA signatures packed in format as is described in [RFC2459] and "dss_signature_blob" format as is specified in "SecSH Transport" draft and [RFC4253].
      Note "SSH Transport Layer Protocol" internet draft before version 12 specify "x509v3-sign-dss" public key algorithm to use signature format as 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 requires 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://roumenpetrov.info/e_nss/. 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 PKIX-SSH is build without "X.509 store" support. Ofr instance at configure script is run with --disable-x509store option. In additional client is able to verify remote key using DNS with CERT RR (resource record).
  • validation
    • CRL (default feature)
      When a X.509 certificate is used in authentication, server and client 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 PKIX-SSH is build without "X.509 store" feature.
    • OCSP (default feature)
      Additional validation is performed when PKIX-SSH is configured to use OCSP and a X.509 certificate is used in authentication.
    ssh can verify host identification using CERT Resource Record published in DNS.
  • PKIX-SSH Agent (ssh-agent and ssh-add programs)
    Authentication agent can hold X.509 certificates.
  • ssh-keyscan
    This tools can gather in addition following X.509 host keys:
    • x509v3-sign-rsa
    • x509v3-sign-dss
    • x509v3-ecdsa-sha2-nistp256
    • x509v3-ecdsa-sha2-nistp384
    • x509v3-ecdsa-sha2-nistp521
  • ssh-keysign
    This tools used in "Host-Based Authentication" can sign "host keys" containing X.509 certificate (RSA, DSA, ECDSA).
  • ssh-keygen
    when user identity contain a X.509 certificate, command:
    • creates public key and proposed "SECSH Public Key File Format" for that certificate.
    • shows fingerprint of certificate.
    • prints CERT RR (resource record) for specified hostname.
  • regression tests
  • manual pages
  • README.x509v3
    Brief description of server and client configuration, regression tests, troubleshooting and FAQ.

Get your version from download pages.


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


  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 PKIX-SSH 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 PKIX-SSH 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 PKIX-SSH 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) PKIX-SSH 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) PKIX-SSH 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(RSA) from PKCS11 module. Since this version sha1 is preferred algorithm and programs start to identify as PKIX in comment from ssh identification string.
    Build for android host is supported since version 7.2 (22 Apr. 2012). With version 7.5(19 May 2013) "known hosts" file may contain distinguished name of host X.509 certificate.
  8. Elliptic
    Version 8.0 (11 Aug.2014) is first secure shell implementation that support X.509 ECDSA algorithm as defined in [RFC6187].

News archives:


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 : Wednesday March 18, 2015 [empty image]