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.0 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.0 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.