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 
(sshg3) 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, /opt/tectia/etc/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, 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 
SSH Tectia client tools for z/OS, do the following steps as ClientUser:
 
-   Generate a host key. By default, 
/opt/tectia/etc/hostkey and 
/opt/tectia/etc/hostkey.pub are generated during installation, so you 
can skip this step. Otherwise, give the following command as a UID 0 user: 
# /opt/tectia/bin/ssh-keygen-g3 -P /opt/tectia/etc/hostkey
 
 -  Add the following line in the 
ssh-broker-config.xml file:
<authentication-methods>
  <authentication-method name="hostbased" />
  ...
</authentication-methods>
  | 
Also other authentication methods can be listed. Place the least 
interactive method first (this means usually the host-based method).
 -   Change the 
DefaultDomain element in the 
ssh2_config file to reflect your fully qualified domain: 
DefaultDomain   .example.com
  | 
Note: On SSH Tectia Server 6.1 for IBM z/OS, the ssh2_config file is used solely 
for host-based authentication and it does not exist by default. You have to 
create it in /opt/tectia/etc/ssh2_config or $HOME/.ssh2/ssh2_config.
Setting this is mandatory if the 
HostbasedAuthForceClientHostnameDNSMatch keyword in the 
sshd2_config file on Server has been set to yes. 
But even if HostbasedAuthForceClientHostnameDNSMatch is not used, 
the DefaultDomain keyword is useful on systems that report only the 
short hostname by default.
 
 
  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, the host 
certificate must be stored in software (ssh-signer2 cannot 
access it from SAF).
 To enable host-based authentication with certificates on SSH Tectia client tools 
for z/OS, do the following steps as ClientUser:
 
-  Add the following line in the 
ssh-broker-config.xml file:
<authentication-methods>
  <authentication-method name="hostbased" />
  ...
</authentication-methods>
  | 
 -  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.
 -   Define the private key and certificate in 
sshd2_config on Client:
HostKeyFile              <private key>
HostCertificateFile      <server-certificate>
  | 
 -   Change the 
DefaultDomain element in the 
ssh2_config file to reflect your fully qualified domain: 
DefaultDomain   .example.com
  | 
Note: On SSH Tectia Server 6.1 for IBM z/OS, the ssh2_config file is used solely 
for host-based authentication and it does not exist by default. You have to 
create it in /opt/tectia/etc/ssh2_config or $HOME/.ssh2/ssh2_config.