SSH Tectia  
Previous Next Up [Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Using SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
        Using the z/OS System Authorization Facility
        Server Authentication with Public Keys in File >>
        Server Authentication with Certificates >>
            Server Configuration
            Client Configuration
        User Authentication with Passwords
        User Authentication with Public Keys in File >>
        User Authentication with Certificates >>
        Host-Based User Authentication >>
        User Authentication with Keyboard-Interactive >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Examples of Use >>
    Man Pages >>
    Log Messages >>

Server Configuration

SSH Tectia Server for IBM z/OS can be configured to support either public-key or certificate authentication. With certificate authentication, the private key and certificate can be stored either in SAF or in file.

It is also possible to configure the server to use a key from SAF and use only the public key extracted from the certificate for authentication.

If a SAF key is configured but the key cannot be found or ICSF is required but not available, the server will issue an error message and will not start up.

Certificates Stored in File

To configure SSH Tectia Server for IBM z/OS to authenticate itself using X.509 certificates from file, perform the following tasks:

  1. Enroll a certificate for the server. This can be done, for example, with the ssh-cmpclient or ssh-scepclient command-line tools. Note that the DNS address extension (dns) in the certificate needs to correspond to the fully qualified domain name of the server. Example: Key generation and enrollment using ssh-cmpclient:
    > ssh-cmpclient INITIALIZE \ 
       -p 62154:secret \
       -P generate://ssh2@rsa:1024/testserv-rsa \
       -s "C=FI,O=SSH,CN=testserv;dns=testserv.ssh.com" \
       -o /etc/ssh2/testserv-rsa \
       -S http://fw.example.com:1080 \
       http://pki.example.com:8080/pkix/ \
       'C=FI, O=SSH, CN=Test CA 1'
    
    For more information on the ssh-cmpclient and ssh-scepclient, see Appendices ssh-cmpclient and ssh-scepclient.
  2. Define the private key and the server certificate in the /etc/ssh2/sshd2_config file, for example, using the key and certificate created above:
     
    HostKeyFile              testserv-rsa.prv
    HostCertificateFile      testserv-rsa-0.crt
    HostKey.Cert.Required    no
    
    Setting the HostKey.Cert.Required option to yes defines that the server must authenticate with a certificate. When keys in file are used, a certificate must be defined with the HostCertificateFile option. Setting the option to no (default) means that the server can use either a normal public key or a certificate, depending on which of them is configured.
  3. Restart the server as instructed in Section Starting the Server.

For more information on the configuration file options, see sshd2_config.

Certificates Stored in SAF

The following example assumes that the SSHD2 user created in Section Creating the SSHD2 User is used to run the server.

To use SAF certificates for authenticating the server, do the following steps. Replace the names and IDs with those appropriate to your system:

  1. Create the server host key in SAF by giving the following TSO commands:
    RACDCERT ID(SSHD2) GENCERT SUBJECTSDN(CN('LPAR1') OU('RD') 
      O('EXAMPLE')) SIZE(1024) WITHLABEL('LPAR1.EXAMPLE.COM')
    RACDCERT ID(SSHD2) LIST
    
  2. Give the following TSO command to generate the certification request:
    RACDCERT ID(SSHD2) GENREQ(LABEL('LPAR1.EXAMPLE.COM')) 
      DSN('SSHD2.LPAR1.CRT.REQ')
    
  3. Use the PKCS#10 certification request in the dataset 'SSHD2.LPAR1.CRT.REQ' to enroll the certificate. The actual steps depend on your CA setup.
  4. After the enrollment is completed, store the received certificate to a dataset, for example 'SSHD2.LPAR1.CRT'.
  5. To connect the new certificate to a key ring, give the following TSO commands:
    RACDCERT ID(SSHD2) ADD('SSHD2.LPAR1.CRT') TRUST 
      WITHLABEL('LPAR1.EXAMPLE.COM')
    RACDCERT ID(SSHD2) ADDRING(SSH-HOSTKEY)
    RACDCERT ID(SSHD2) CONNECT(ID(SSHD2) LABEL('LPAR1.EXAMPLE.COM') 
      RING(SSH-HOSTKEY) USAGE(PERSONAL))
    RACDCERT ID(SSHD2) LISTRING(SSH-HOSTKEY)
    
  6. For the settings to take effect, give the following TSO command:
    SETROPTS RACLIST(DIGTCERT) REFRESH
    
  7. Define the z/OS SAF external key provider in the /etc/ssh2/sshd2_config file:
    HostKeyEkProvider        zos-saf
    HostKeyEkInitString      "KEYS(ID(SSHD2) RING(SSH-HOSTKEY) 
      LABEL('LPAR1.EXAMPLE.COM'))"
    HostKey.Cert.Required    yes
    
    Note that HostKeyEkInitString must point to a single private key. Setting the HostKey.Cert.Required option to yes defines that the server must authenticate with a certificate. When the z/OS SAF provider is used, setting the option to no means that only the public key found in the SAF certificate is used.

For more information on the configuration file options, see sshd2_config. For information on the format of the external key initialization string, see ssh-externalkeys.

Previous Next Up [Contents] [Index]


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

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