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 username 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 dataset, 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 dataset, 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 username patterns for which the login name given by the user is not used but the real username 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 username of the user. If the user certificate has the correct hostname in the HostIdMapping hostname field, the username associated with that hostname (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 hostname. 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 hostnames that the server recognizes. If the user certificate has a matching hostname in the HostIdMapping hostname field, the username associated with that hostname (specified in the certificate) s 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 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- certdas instructed in Restarting and Stopping