Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.
SSH Tectia Server for IBM z/OS uses the Integrated Cryptographic Services Facility (ICSF) if the UseCryptoHardware configuration variable allows it (see Section Crypto Hardware Support) or keys and certificates are stored in the System Authorization Facility (SAF) and the keys are of type ICSF or PCICC (see Server Certificates Stored in SAF and User Certificates Stored in SAF). SAF will control the use of cryptographic services if the CSFSERV class is activated and will control the access to cryptographic keys if the CSFKEYS class is activated.
When using SAF private keys, the server or client user needs access to the CSFDSG resource in the CSFSERV class. The private keys can be secured by permitting access to a resource in the CSFKEYS class. The name of the resource is the label of the key in the ICSF key database.
See the IBM document z/OS ICSF Administrator's Guide, chapter "Controlling Who Can Use Cryptographic Keys and Services" for instructions on how to use generic resource names, how to give permissions to user groups and connect users to groups, and how to define auditing.
The users (including the SSHD2 user) must have at least READ access to the IRR.DIGTCERT.LISTRING facility. If a user needs access to a key ring belonging to another user, he must have UPDATE access to the facility. This case will arise when using a KnownHostsEkProvider for checking host certificates, because host certificates are best entered as SITE keys and are not owned by the verifier.