Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Getting Started with SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
    File Transfer Using SFTP >>
    File Transfer Using Transparent FTP Tunneling >>
    Tunneling on the Command Line >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
        ssh-socks-proxy >>
        ssh-socks-proxy-config >>
            Document Type Declaration and the Root Element
            The general Element
            The default-settings Element
            The profiles Element
            The static-tunnels Element
            The filter-engine Element
            The logging Element
        ssh-socks-proxy-ctl >>
        ssh-certview >>
        ssh-cmpclient >>
        ssh-keydist2 >>
        ssh-scepclient >>
    Log Messages >>

The general Element

The general element contains settings such as the cryptographic library and the key stores to be used.

  • cert-validation

    This element defines public-key infrastructure (PKI) settings used for validating remote server authentication certificates. The element can have three attributes: end-point-identity-check, default-domain, http-proxy-url, and socks-server-url.

    The end-point-identity-check attribute specifies whether the client will verify the server's hostname against the Subject Name or Subject Alternative Name (DNS Address) in the server's certificate. If set to no, the fields in the server host certificate are not verified and the certificate is accepted based on validity period and CRL check only. Note that this is a possible security risk, as anyone with a certificate issued by the same trusted CA that issues the server host certificates can perform a man-in-the-middle attack on the server if a client has the end-point identity check disabled. The default value is yes.

    The default-domain attribute can be used when the end-point identity check is enabled. It specifies the default domain part of the remote system name and it is used if only the base part of the system name is available. The default-domain is appended to the system name if it does not contain a dot (.).

    If the default domain is not specified, the end-point identity check fails, for example, when a user tries to connect to a host "rock" giving only the short hostname and the certificate contains the full DNS address "".

    The http-proxy-url attribute defines a HTTP proxy and the socks-server-url attribute defines a SOCKS proxy for making LDAP or OCSP queries for certificate validity.

    The address of the proxy is given as the value of the attribute. The format of the address with a SOCKS proxy is:

    socks://user@socks_srv:port/network/netmask,network/netmask ...

    The format of the address with an HTTP proxy is:

    http://user@proxy_srv:port/network/netmask,network/netmask ...

    For example, by setting socks-server-url to


    the host and port 1080 are used as your SOCKS server for connections outside of networks (16-bit domain) and (8-bit domain). Those networks are connected directly.

    The cert-validation element can contain multiple ldap-server and ocsp-responder elements, a dod-pki element, and multiple ca-certificate elements.

    • ldap-server

      This element specifies an LDAP server address and port used for fetching CRLs and/or subordinate CA certificates based on the issuer name of the certificate being validated. Several LDAP servers can be specified by using several ldap-server elements.

      CRLs are automatically retrieved from the CRL distribution point defined in the certificate to be verified if the point exists.

      The default value for port is 389.

    • ocsp-responder

      This element specifies an OCSP (Online Certificate Status Protocol) responder service address in URL format (url). Several OCSP responders can be specified by using several ocsp-responder elements.

      If the certificate has a valid Authority Info Access extension with an OCSP Responder URL, it will be used instead of this setting. Note that for the OCSP validation to succeed, both the end-entity certificate and the OCSP Responder certificate must be issued by the same CA.

      The validity-period (in seconds) can be optionally defined. During this time, new OCSP queries for the same certificate are not made but the old result is used. The default validity period is 0 (a new query is made every time).

    • dod-pki

      This element defines whether the certificates are required to be compliant with the DoD PKI (US Department of Defense Public-Key Infrastructure). In practise, this means that the Digital Signature bit must be set in the Key Usage of the certificate. The enable attribute can have a value of yes or no. The default is no.

    • ca-certificate

      This element defines a CA used in server authentication. It can have four attributes: name, file, disable-crls, and use-expired-crls.

      The name attribute must contain the name of the CA.

      The element must either contain the path to the X.509 CA certificate file as a value of the file attribute, or include the certificate as a base64-encoded ASCII block.

      CRL checking can be disabled by setting the disable-crls attribute to yes. The default is no.

      Expired CRLs can be used by setting a numeric value (in seconds) for the use-expired-crls attribute. The default is 0 (do not use expired CRLs).

    An example of a certificate validation configuration is shown below:

    <cert-validation end-point-identity-check="yes" 
      <ldap-server address="ldap://" />
      <ocsp-responder url="" validity-period="0" /> 
      <dod-pki enable="no" />
      <ca-certificate name="ssh_ca1"
                      use-expired-crls="100" />

  • key-stores

    There can be one <key-stores> instance under the <general> element. It can have any amount of <key-store> elements each of which configures one key store provider.

    • key-store

      The key-store element has two attributes: type and init. The type attribute is the key store type. Currently supported type is "software". The init attribute is the key-store-provider-specific initialization info.

    See the end of Section Key Store Configuration Examples for key store configuration examples.

  • strict-host-key-checking

    This element enables strict host key checking. If it is enabled, the SOCKS Proxy never adds host keys to the user's .ssh2/hostkeys directory upon connection, and refuses to connect to hosts whose key has changed. This provides maximum protection against man-in-the-middle attacks. However, it can be somewhat annoying if you frequently connect to new hosts.

    The word yes or no is given as the value of the enable attribute. The default is no (the user is asked whether to accept a new or changed host key).

    Strict host key checking will be used, if it is so specified in either the global or the user configuration file (or both).

    <strict-host-key-checking enable="yes" />

  • accept-unknown-host-keys

    This element defines whether the SOCKS Proxy will always accept the proposed host key without saving the key. It is the equivalent of automatically answering "Once" to all accept-host-key prompts.

    The word yes or no is given as the value of the enable attribute. The default is no (unknown host keys are not automatically accepted).

    If this element is set to no either in the global or the user configuration file, the changed or new host keys are prompted normally. Additionally, setting this element to yes takes effect only when both strict-host-key-checking and host-key-always-ask are set to no (or are not explicitly defined).

    <accept-unknown-host-keys enable="no" />

    Note: When transparent tunneling is used, accepting the host key cannot be prompted from the user. Either this setting must be set to yes (not recommended) or the host keys of the Secure Shell tunneling servers must be obtained beforehand and stored based on the IP addresses of the servers, for example, by using the key distribution tool. See Section Fetching Remote Server Keys.

    Caution: Consider carefully before enabling this option. Disabling the host-key checks can make you vulnerable to a man-in-the-middle attack.

  • known-hosts

    This element specifies the location of an OpenSSH-style known-hosts file that contains the public key data of known server hosts. The full path to the known_hosts file must be given as a value of the path attribute.

    <known-hosts path="/u/username/.ssh/known_hosts" />

    The hostname(s) in the file must be in clear-text format. Hashed hostnames are not supported.

Key Store Configuration Examples

Software provider

The software provider handles key pairs stored on disk in standard Secure Shell v2 or legacy OpenSSH formats and X.509 certificates stored in native X.509, PKCS#7, and PKCS#12 formats.

To add a single key file (for example, /u/exa/keys/enigma and /etc/my_key), specify both the private key file and the public key file:

  <key-store type="software" 
             init="key_files(/u/exa/keys/,/u/exa/keys/enigma)" />
  <key-store type="software" 
             init="key_files(/etc/,/etc/my_key)" />

To add all keys from a specific directory (for example all keys from /u/exa/keys and /etc/keys):

  <key-store type="software" 
             init="directory(path(/u/exa/keys))" />
  <key-store type="software" 
             init="directory(path(/etc/keys))" />

PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2007 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now