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

26 Aug 2016 : Version x509-9.1
What's new:
  • Updates in supported OpenSSL API versions
    OpenSSL 1.1.0 is published on 25 Aug 2016. Unfortunately in last few weeks API is changed again. PKIX-SSH version 9.1 is updated to release version of OpenSSL 1.1 API.
    Until now PKIX-SSH still support OpenSSL 0.9.6 API, although build raise error if detect OpenSSL version before 0.9.7. Finally specific PKIX-SSH workaround for OpenSSL 0.9.6 is removed from code.
  • recent autotool configuration
    Update to recent version detection (config.guess) and validation (config.sub) scripts. Configure script is generated with autoconf 2.69.
  • ECDSA algorithms in documentation
    Manual pages and readme first list ECDSA, then for RSA and DSA X.509 public key algorithms. Documentation order match how code list public key algorithms in order of precedence.
  • do not generate missing rsa1 keys
    Default startup script will not generate missing rsa1 keys if support for SSH1 is not enabled.

3 Aug 2016 : Version x509-9.0
What's new:
  • internal build of certificate chain
    Public key algorithms described in [RFC6187] require a chain of certificates leading to a trusted certificate authority to be sent as part of public key data.
    Before version 9.0 it was user responsibility to specify those certificates as part of private key file. It was not possible for keys and X.509 certificates stored in external devices to satisfy [RFC6187] requirement. Now when a [RFC6187] key is loaded programs (client, server) use certificates from private file and X.509 store to build the chain.
    PKCS11 module is a specific case. It is case when module is used with agent (ssh-add -s ..). Now ssh agent support certificate X.509 and use system default store defined at build time. In addition new ssh-add option -S allows user to add extra certificates to store. Those certificates and system default are used to build certificate chain.
  • remove build option --disable-x509store
    Support of [RFC6187] public key algorithms require working X.509 store.
  • remove build option --enable-x509v3-ecdsa
    Support of x509v3-ecdsa-sha2-... now is default for X509KeyAlgorithm option. With other words support for X.509 certificates with EC is considered complete.
  • port to OpenSSL 1.1 API
    Most of code is rewritten to use API from OpenSSL 1.1 development branch.
    The new API is back-ported locally and used if build is with OpenSSL versions before 1.1. The model for functional checks at configure time allows build with OpenSSL compatible libraries.
  • Android port
    Code is updated to support various versions of Bionic "C" libraries.
    Now specific to Android logging functionality is used from all executable.
    A simplified password file is managed. It supports only one password record with md5 hash. This allows ssh daemon to support password authentication.
  • dump of configuration
    Command that dump client/server configurations now properly generate directive VAType.

2 Aug 2016 : Version x509-9.0
New major release in progress...



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.
    • "PKCS#11"module
      As second option PKIX-SSH could use PKCS#11 shared library(module) to communicate with EC or RSA X.509 certificates and private key provided by PKCS#11 tokens.
  • 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.
  • CERT RR
    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
    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 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] - initialy for client and server. With version 8.2 (23 Nov. 2014) adds support of X.509 ECDSA algorithm in agent. From version 8.4 (1 Jul 2015) EC keys or X.509 certificates stored on external device could be used with loadable cryptographic modules - OpenSSL engines.
    Support for FIPS environments is enhanced in version 8.1 (29 Sep. 2014) with fipscheck for "Red Hat" FIPS validated environment. Version 8.2 (23 Nov. 2014) is succesfully tested with Solaris 11.2 FIPS validated OpenSSL module.
    Lists with allowed algorithms support patterns since version 8.3 (18 Mart 2015).
    Support for EC keys and certificates stored in PKCS#11 tokens is added in version 8.8 (29 Feb 2016).

News archives:

Miscellaneous:

Recommendet OpenSSL library versions:
Before to use X.509 certificates please read OpenSSL security advisories:
OpenSSL library versions:

[empty image]
[empty image] [empty image] Last modified : Saturday August 27, 2016 [empty image]