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
.