Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tectia 
PreviousNextUp[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 >>
        User Authentication with Passwords
        User Authentication with Public Keys in File >>
        User Authentication with Certificates >>
        Host-Based User Authentication >>
            Client Configuration
            Server Configuration
            Optional Configuration Settings
        User Authentication with Keyboard-Interactive >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Examples of Use >>
    Man Pages >>
    Log Messages >>

Client Configuration

When a user connects to a server using host-based authentication, it must prove that it has proper client host credentials (host private key, host public key, and/or host certificate). As the client itself (ssh2) cannot access host private key there is separate binary (ssh-signer2) that has sufficient permissions for private key operations. ssh-signer2 reads default server configuration file, /etc/ssh2/sshd2_config.

Host-based authentication can be enabled either by using traditional public keys or by using certificates. In SSH Tectia Server for IBM z/OS 5.3, the host public key and/or certificate must be stored in software (ssh-signer2 cannot access it from SAF).

Traditional Public Keys Stored in File

To enable host-based authentication with traditional public keys on the client, do the following steps as ClientUser:

  1. Generate a host key. By default, /etc/ssh2/hostkey and /etc/ssh2/hostkey.pub are generated during installation, so you can skip this step. Otherwise, give the following command:
    > /usr/lpp/ssh2/bin/ssh-keygen2 -P /etc/ssh2/hostkey
    
  2. Add the following line in the /etc/ssh2/ssh2_config (or $HOME/.ssh2/ssh2_config) file:
    AllowedAuthentications   hostbased
    
    Also other authentication methods can be listed. Place the least interactive method first. For example:
    AllowedAuthentications   hostbased,publickey,password
    
  3. Change the DefaultDomain keyword in the ssh2_config file to reflect your fully qualified domain:
    DefaultDomain            example.com
    
    Setting this is mandatory if the HostbasedAuthForceClientHostnameDNSMatch keyword in the /etc/ssh2/sshd2_config file on Server has been set to yes. But even if HostbasedAuthForceClientHostnameDNSMatch is not used, the DefaultDomain keyword is useful, for example, on AIX and Solaris, which report only the short hostname by default.

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

Certificates Stored in File

It is possible to use a certificate instead of the traditional public-key pair to authenticate the client host. In SSH Tectia Server for IBM z/OS 5.3, the host certificate must be stored in software (ssh-signer2 cannot access it from SAF).

To enable host-based authentication with certificates on the client, do the following steps as ClientUser:

  1. Add the following line in the /etc/ssh2/ssh2_config (or $HOME/.ssh2/ssh2_config) file:
    AllowedAuthentications   hostbased
    
  2. Enroll a certificate for client. See User Authentication with Certificates for more information. The certificate must contain a dns extension which contains the fully qualified domain name (FQDN) of client. Note that the private key associated with the certificate needs to be stored with an empty passphrase.
  3. Define the private key and certificate in sshd2_config on client:
    HostKeyFile              <private key>
    HostCertificateFile      <server-certificate>
    
  4. Change the DefaultDomain keyword in the ssh2_config file to reflect your fully qualified domain:
    DefaultDomain            example.com
    

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

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

===AUTO_SCHEMA_MARKUP===