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

Server Certificates Stored in SAF

[Note]Note

If there is at least one general/known-hosts/key-store element configured, SAF validation will be used and Tectia validation will not be used. This is different from Tectia Server for IBM z/OS version 5.x, where you could specify saf,tectia, and both validations were performed and both had to succeed.

To configure the client to trust the server's SAF certificate by using SAF validation only, perform the following tasks. Replace the names and IDs with those appropriate to your system:

  1. Get the server host certificate and store it to a data set, for example 'SERVER1.CRT'.

  2. To add the server certificate into SAF, give the following TSO commands:

    RACDCERT ID(USER) ADD('SERVER1.CRT') TRUST WITHLABEL('SERVER1')
    RACDCERT ID(USER) ADDRING(SSH-HOSTKEYS)
    RACDCERT ID(USER) CONNECT(ID(USER) LABEL('SERVER1') RING(SSH-HOSTKEYS) 
      USAGE(PERSONAL))
    RACDCERT ID(USER) LISTRING(SSH-HOSTKEYS)
    
  3. For the settings to take effect, give the following TSO command:

    SETROPTS RACLIST(DIGTCERT) REFRESH
    
  4. Define the z/OS SAF external key provider that contains the server host certificates in the general/known-hosts/key-store element:

    <known-hosts>
    ...
      <key-store type="zos-saf" 
                 init="KEYS(ID(USER) RING(SSH-HOSTKEYS))" />
    </known-hosts>
    

For more information on the configuration file options, see ssh-broker-config(5). For information on the format of the external key initialization string, see the section called “Key Store Configuration Examples”.

===AUTO_SCHEMA_MARKUP===