Your browser does not allow storing cookies. We recommend enabling them.

SSH

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 the host private key, there is a separate binary (ssh-signer2) that has sufficient permissions for private key operations. ssh-signer2 reads the 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 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 Tectia client tools for z/OS, perform the following steps as ClientUser:

  1. 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
    
  2. Add the following line in the ssh-broker-config.xml file:

    <authentication-methods>
      <auth-hostbased />
     ...
    </authentication-methods>
    

    Also other authentication methods can be listed. Place the least interactive method first (this usually means the host-based method).

  3. Change the DefaultDomain element in the ssh2_config file to reflect your fully qualified domain:

    DefaultDomain    .example.com
    
    [Note]Note

    On Tectia Server 6.6 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 host name 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 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 Tectia client tools for z/OS, do the following steps as ClientUser:

  1. Add the following line in the ssh-broker-config.xml file:

    <authentication-methods>
      <auth-hostbased />
      ...
    </authentication-methods>
    
  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 element in the ssh2_config file to reflect your fully qualified domain:

    DefaultDomain            .example.com
    
    [Note]Note

    On Tectia Server 6.6 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.


 

 
Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more