To configure the server to allow user authentication with SAF certificates, perform the following tasks. Replace the names and IDs with those appropriate to your system:
AllowedAuthentications publickey AuthPublicKey.Cert.Required yes
yesdefines that the user must authenticate with a certificate or else the authentication will fail.
safis specified, RACF/SAF is used for validating user certificates. The user certificates must be found in a trusted key ring defined by the
AuthorizationEkProviderkeyword. Note that when only SAF validation is used, the certificate validity period and revocation status are not checked.
tectiais specified (or the keyword is missing from the configuration), the Tectia Certificate Validator (ssh-certd) is used for validating the user certificate. The user certificates must be issued by a trusted certification authority defined in the
If both values are specified, RACF/SAF determines the user name based on the certificate contents. After that the Tectia validation is performed. The CA certificate of the issuing certification authority must be found in a trusted key ring defined by the
Several of the following steps are marked either as SAF validation, SAF validation only, Tectia validation, or Tectia validation only. These steps are alternatives depending on the value of
saf,tectiais selected, both the steps marked as SAF validation and Tectia validation need to be completed.
(SAF validation only) Get the user certificate and store it to a data set, for example
(SAF validation only) To add the user certificate into SAF, give the following TSO commands:
RACDCERT ID(USER) ADD('USER.CRT')TRUST WITHLABEL('USER') RACDCERT ID(USER) ADDRING(USER) RACDCERT ID(USER) CONNECT(ID(USER) LABEL('USER') RING(USER) USAGE(PERSONAL)) RACDCERT ID(USER) LISTRING(USER)
(SAF validation only) For the settings to take effect, give the following TSO command:
SETROPTS RACLIST(DIGTCERT) REFRESH
(Tectia validation) Get the CA certificate and store it to a data set, for example
(Tectia validation) To add the CA certificate into SAF, give the following TSO commands:
RACDCERT CERTAUTH ADD('PKICA.CRT') TRUST WITHLABEL('PKICA') RACDCERT ID(SSHD2) ADDRING(SSH-PKI) RACDCERT ID(SSHD2) CONNECT(CERTAUTH LABEL('PKICA') RING(SSH-PKI) USAGE(CERTAUTH)) RACDCERT ID(SSHD2) LISTRING(SSH-PKI)
(Tectia validation) For the settings to take effect, give the following TSO command:
SETROPTS RACLIST(DIGTCERT) REFRESH
(SAF validation) The
IdentityDispatchUserskeyword in the
/opt/tectia/etc/sshd2_configfile can be used to define user name patterns for which the login name given by the user is not used but the real user name is taken from the user certificate.
(SAF validation) A user certificate might contain a HostIdMapping extension field. That field is used by SAF to determine the local user name of the user. If the user certificate has the correct host name in the HostIdMapping host name field, the user name associated with that host name (specified in the certificate) is used. To use the HostIdMapping extension in user certificates, give the CA certificate the
HIGHTRUSTstatus and give the
SSHD2user READ access to the resource
hostnameis the character string used in the certificate extension. Often the DNS name of the server is used as the host name. To allow SAF to use the HostIdMapping extension, give the following commands:
RACDCERT CERTAUTH ALTER(LABEL('PKICA')) HIGHTRUST RDEFINE SERVAUTH IRR.HOST.LPAR2.EXAMPLE.COM UACC(NONE) PERMIT IRR.HOST.LPAR2.EXAMPLE.COM CLASS(SERVAUTH) ID(SSHD2) ACCESS(READ) SETROPTS RACLIST(SERVAUTH) REFRESH RLIST SERVAUTH IRR.HOST.LPAR2.EXAMPLE.COM ALL
(SAF and Tectia validation) As an alternative to the previous step, when both SAF and Tectia validation are used, the
HostIdMappingHostnameskeyword in the
/opt/tectia/etc/sshd2_configfile can be used to define a list of host names that the server recognizes. If the user certificate has a matching host name in the HostIdMapping host name field, the user name associated with that host name (specified in the certificate) is used.
(SAF validation only) If only SAF validation is used, define the z/OS SAF external key provider that contains the user certificates with the
AuthorizationEkProviderkeyword in the
AuthorizationEkProvider "zos-saf:KEYS(ID(%U) RING(%U))"
AuthorizationEkProviderkeyword can contain special strings in the key specification that are mapped according to the following list:
%U= user name
%IU= user ID
%IG= user group ID
PkiEkProvider "zos-saf:KEYS(ID(SSHD2) RING(SSH-PKI))"
PkiEkProvider "zos-saf:KEYS(ID(SSHD2)RING(SSH-PKI))" MapFile cert-user-mapping.txt
(Tectia validation) If Tectia validation is used, define also the LDAP server(s) used for CRL checks in the
ssh_certd_configfile. If the CA services (OCSP, CRLs) are located behind a firewall, define also the SOCKS server.
LdapServers ldap://ldap.example.com:389 SocksServer socks://fw.example.com:1080
Defining the LDAP server is not necessary if the CA certificate contains a
CRL Distribution Pointor an
Authority Info Accessextension.
(Tectia validation only) If only Tectia validation is used, create the certificate user mapping file as described in Certificate User Mapping File.
(Tectia validation) Restart ssh-certd as instructed in Restarting and Stopping ssh-certd.