Step 2. Distribute the public keys to all remote hosts

In this step, you will distribute the public keys to all remote hosts that you plan to log in to, using public key authentication. Figure 1 shows an example of the steps to follow in order to create an authorized_keys file when keys are stored in key rings.

Export the public keys to remote hosts that store user's keys in a UNIX file (the authorized_keys file).
- On the local host, use ssh-keygen -e to export the public key into a UNIX file.
  Example:
```
_ZOS_SSH_KEY_RING_LABEL="userID/SSHring uniq-ssh-type" ssh-keygen -e > uniq-ssh.type
```
- Use FTP to distribute the uniq-ssh.type file to the remote host.
- On the remote host, use ssh-keygen -i to import the public key, appending it to the authorized_keys file:
```
ssh-keygen -i -f uniq-ssh.type >> ~/.ssh/authorized_keys
```
- You have now completed distribution of the public keys to remote hosts that store user keys in a UNIX files . If you have other remote hosts that store user keys in key rings, then continue on to the next step to export the public keys to remote hosts. Otherwise, you have completed Step 2.
Export the public keys to remote hosts that store users's keys in a certificate associated with a key ring. First, the public keys must be exported from the certificate. The RACDCERT EXPORT command can perform this type of export. Specify the certificate identification and request CERTDER for the export format. Choose a data set to store the exported certificate and specify it on the DSN parameter. If the data set specified for DSN already exists, it is deleted and reallocated by the RACDCERT EXPORT command.
If the public key will be stored in a certificate associated with a key ring on the remote host, then export the certificate in DER format (without the private key) into a data set for each public key that needs to be distributed to remote hosts.
For example:
```
RACDCERT EXPORT(LABEL('uniq-ssh-type')) ID(userID) 
 FORMAT(CERTDER) DSN('userid.sshcert.type')
```
_______________________________________________________________
Use FTP to distribute the exported certificate data set in binary format to the remote hosts.
_______________________________________________________________
On the remote host, create a real key ring if you do not yet have one for your keys. Omit this step if you plan to use a virtual key ring.
```
RACDCERT ID(userID) ADDRING(SSHAuthKeysRing)
```
_______________________________________________________________
On the remote hosts, add each user certificate into the user's SAF database.
The RACDCERT ADD command can be used to add the exported certificate on the remote host. Specify the data set that you copied to the remote host using FTP, the user ID that should own the certificate, and indicate that this certificate is trusted. The specified user ID must be the user ID that you want to be able to connect to from the local host with the matching key. You will specify the label for this certificate on this remote host. This label must be unique for the user ID within the RACF database, and is used to identify this certificate on future commands and in authorized key files.

This certificate only contains the public key.
Example:
```
RACDCERT ADD('userid.sshcert.type') ID(userID) 
 WITHLABEL('uniq-ssh-type') TRUST
```
_______________________________________________________________
On the remote hosts, connect each certificate to the user's key ring.
The RACDCERT CONNECT command can be used to connect each certificate to the user's key ring if real key rings are being used. Omit this step if virtual key rings are being used and go to Step 7. You must identify both the user ID that owns the certificate and the user ID that owns the key ring. These will normally be the same for this connect command.
Example:
```
RACDCERT	CONNECT(ID(userID) LABEL('uniq-ssh-type') 
 RING(SSHAuthKeysRing) USAGE(PERSONAL)) ID(userID)
```
_______________________________________________________________
On the remote host, edit the authorized_keys file to add one line containing the zos-key-ring-label option for each public key that was added to the key ring. (See Format of the authorized_keys file in the sshd command section for more information.)
For example:
- If a real key ring is being used, add the following line:
```
zos-key-ring-label="userID/SSHAuthKeysRing uniq-ssh-type" 
```
- If a virtual key ring is being used, add the following line:
```
zos-key-ring-label="userID/* uniq-ssh-type"
```
_______________________________________________________________
On the remote host, permit access to this key ring for the user. There are two ways to provide access: ring-specific profile checking and global profile checking. Both are discussed in Managing key rings and restricting access to them.
For example:
- To define individual user access to the real key ring, SSHAuthKeysRing, using ring-specific profile checking:
```
RDEFINE RDATALIB userID.SSHAuthKeysRing.LST UACC(NONE)
PERMIT userID.SSHAuthKeysRing.LST CLASS(RDATALIB) ID(userID) 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 define individual user access to the virtual key ring, using ring-specific profile checking:
```
RDEFINE RDATALIB userID.IRR_VIRTUAL_KEYRING.LST UACC(NONE)
PERMIT userID.IRR_VIRTUAL_KEYRING.LST CLASS(RDATALIB) ID(userID) 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 define individual user access, using global profile checking:
```
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(READ)
```
  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, you have set up user authentication when using key rings to store keys. Every time the user keys are regenerated in the key ring, they must be redistributed and added to the key ring on the remote systems that contain the authorized keys.