Step 1: Generate the host keys for the SSH server

Before you begin: You need to do the following tasks:

Make sure that a unique user ID that will be used to start the OpenSSH daemon has already have been set up on your system. A unique user ID is necessary because RACF® uses the user ID, not the UNIX UID, for access control to key rings. The examples in this step use SSHDAEM as the user ID that starts the daemon and that also owns the associated host key rings. For more information about setting up the user ID that will be used to start the OpenSSH daemon, see Starting sshd as a stand-alone daemon.
Determine whether you are working with real or virtual key rings because the setup steps vary depending on the type of key ring is being used. See z/OS Security Server RACF Security Administrator's Guide for more information about real and virtual key rings.

Perform the following steps to generate the host keys for the SSH server.

Create a real key ring if you do not yet have one to use for the host public keys. Omit this step if you plan to use a virtual key ring. Use the RACDCERT ADDRING command to create the new key ring, specifying the owning user ID and the key ring name. The ID keyword must specify the user ID that will be starting sshd. The key ring name can be any unique name for this user ID.
For example:
```
RACDCERT ID(SSHDAEM) ADDRING(SSHDring)
```
_______________________________________________________________
Using the RACDCERT GENCERT command, generate a host certificate with public and private keys based on the algorithms that are supported on the server (either RSA, DSA, or both). For RSA keys, the minimum size is 768 bits and the maximum size is 32768 bits. Typically, 2048 bits are considered sufficient. DSA keys can be 1024 bits in both FIPS and non-FIPS mode. Since DSA 2048 isn't supported by open group OpenSSH, z/OS OpenSSH may not communicate with open group OpenSSH if DSA 2048 key is used. It requires that both client and server be z/OS OpenSSH and running in FIPS mode, if DSA 2048 is used. DSA keys larger than 2048 bits associated with certificates in a key ring are not supported by OpenSSH.
Do not use variant characters in the label name for the certificate. The sshd daemon must run only in the C locale and therefore interprets the key files (that is, the known host and authorized key files) as encoded in code set IBM-1047.
The following examples demonstrate how to create non-ICSF (Integrated Cryptographic Storage Facility) certificates in the RACF database.
Note: ICSF can not be used to store the certificates and associated keys.
- To generate a certificate and an RSA public/private key pair, storing the private key in the RACF database as a non-ICSF key:
```
RACDCERT GENCERT ID(SSHDAEM) SUBJECTSDN(CN('host-ssh-rsa-cn')) 
SIZE(2048) WITHLABEL('host-ssh-rsa')
```
- To generate a certificate and a 1024 DSA public/private key pair, storing the private key in the RACF database as a non-ICSF key:
```
RACDCERT	GENCERT ID(SSHDAEM) SUBJECTSDN(CN('host-ssh-dsa-cn')) 
SIZE(1024) DSA WITHLABEL('host-ssh-dsa')
```
- To generate a certificate and a 2048 DSA public/private key pair, storing the private key in the RACF database as a non-ICSF key:
```
RDEFINE FACILITY IRR.DSA.SHA256 UACC(NONE)
SETROPTS RACLIST(FACILITY) REFRESH
RACDCERT GENCERT ID(SSHDAEM) SUBJECTSDN(CN(’host-ssh-dsa-cn’)) 
SIZE(2048) DSA WITHLABEL(’host-ssh-dsa’)
```
The SUBJECTSDN parameter offers several more customizable keywords, which are not shown in the preceding examples, that can be included in the distinguished name. The label assigned to the certificate must be chosen to be unique within the RACF database. The user ID must match the owner of the key ring.

_______________________________________________________________
If real key rings are being used, use the RACDCERT CONNECT command to connect the certificate to the host key ring. Omit this step if you plan to use virtual key rings. You must identify the user ID that owns the certificate and the user ID that owns the key ring. These are typically the same for this connect command. For example:
```
RACDCERT	CONNECT(ID(SSHDAEM) LABEL('host-ssh-type')
	RING(SSHDring) USAGE(PERSONAL)) ID(SSHDAEM)
```
_______________________________________________________________
Add a line in the z/OS-specific zos_sshd_config file for each certificate being used for a host key.
- For real key rings, add the following line:
```
HostKeyRingLabel	"SSHDAEM/SSHDring host-ssh-type"
```
- For virtual key rings, add the following line:
```
HostKeyRingLabel "SSHDAEM/* host-ssh-type"
```
_______________________________________________________________
Restrict access to the key ring. To prevent access to the host private keys by any other user, permit only the user ID (for example, SSHDAEM) that starts the sshd daemon. See Managing key rings and restricting access to them for more information. For example:
- To prohibit universal access to SSHDring, using ring-specific profile checking:
```
RDEFINE RDATALIB SSHDAEM.SSHDring.LST UACC(NONE)
PERMIT SSHDAEM.SSHDring.LST CLASS(RDATALIB) ID(SSHDAEM) ACCESS(READ)
```
  If the RDATALIB class is not yet active and RACLISTed:
```
SETROPTS RACLIST(RDATALIB) CLASSACT(RDATALIB)     
```
  Refresh the class:
```
SETROPTS RACLIST(RDATALIB) REFRESH
```
- To prohibit universal access to the SSHDAEM user's virtual key ring, using ring-specific profile checking:
```
RDATALIB SSHDAEM.IRR_VIRTUAL_KEYRING.LST UACC(NONE)
PERMIT SSHDAEM.IRR_VIRTUAL_LISTRING.LST CLASS(RDATALIB) ID(SSHDAEM) ACCESS(READ)
```
  If the RDATALIB class is not yet active and RACLISTed:
```
SETROPTS RACLIST(RDATALIB) CLASSACT(RDATALIB) 
```
  Refresh the class:
```
SETROPTS RACLIST(RDATALIB) REFRESH
```
- To prohibit universal access to any key ring on the system, using global profile checking:
```
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
```
  If the FACILITY class is not yet active and RACLISTed:
```
SETROPTS RACLIST(FACILITY) CLASSACT(FACILITY)
```
  Refresh the class:
```
SETROPTS RACLIST(FACILITY) REFRESH
```
_______________________________________________________________

When you are done with Step 1, you have generated the host keys for the SSH server. Now go to Step 2: Distribute the public keys from the local host to the remote hosts.