[Contents] [Index]

About This Document >>     Installing SSH Tectia Server for IBM z/OS >>     Getting Started with SSH Tectia Server for IBM z/OS >>     Setting up Non-Interactive Server and User Authentication >>         Key Distribution Tool         Authenticating Remote Server Hosts             Fetching Remote Server Keys         Using Password for User Authentication         Using Public Key for User Authentication >>     Setting up Non-Interactive Secure File Transfer >>

Fetching Remote Server Keys

The SSH Tectia clients on the mainframe must have the remote server public keys or public key hash values available in order to authenticate the remote server they are connecting to. The keys or key hash values can be stored in the mainframe user's $HOME/.ssh2/hostkeys directory or in the /opt/tectia/etc/hostkeys directory which is common for all the users. The key distribution tool can be used to retrieve multiple remote host keys and store the keys or key hash values to the user's host key directory or to the system-wide key store that is available for all the users.

For more information about hashed host key format, see Section Authenticating Remote Server Hosts.

Examples of Fetching Remote Server Keys

The following examples illustrate using ssh-keydist-g3 for fetching remote server host keys.

Caution: When ssh-keydist-g3 is run with the -N option, it accepts the received host keys automatically without prompting the user. You should verify the validity of keys after receiving them or you risk being subject to a man-in-the-middle attack.

Example 1: Using USS

This example is run under USS shell. Multiple host keys are fetched in verbose mode and saved in plain format under the user's $HOME/.ssh2/hostkeys directory. The host keys are also saved using the IP addresses of the hosts. The log is stored under /tmp. The log will list the accepted keys and their fingerprints. You should verify them after running the command.

> ssh-keydist-g3 --verbose --accept-host-keys --accept-host-keys-also-by-ip \ 
--accepted-host-key-filename-format plain \
--accepted-host-key-log /tmp/newhosts.log \ 
host1 host2 host3

Example 2: Using JCL

This example HOSTSAVE from SAMPLIB presents a JCL script that does the same steps as the USS command in Example 1 above (options are given in short format):

//HOSTSAVE EXEC PGM=IKJEFT1A, // REGION=0M //SYSTSPRT DD SYSOUT=* //STDOUT DD PATH='/tmp/&SYSUID.-HOSTSAVE.out', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=(SIRUSR,SIWUSR) //STDERR DD PATH='/tmp/&SYSUID.-HOSTSAVE.err', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=(SIRUSR,SIWUSR) //STDENV DD DSN=&SYSUID..SSZ.SRVR608.PARMLIB(SSHENV), // DISP=SHR //SYSTSIN DD * BPXBATCH SH /opt/tectia/bin/ssh-keydist-g3 + -v -N -i -F plain -A /tmp/newhosts.log + host1 host2 host3 /* //* //PROUT EXEC PGM=IKJEFT1A, // PARM='OCOPY INDD(STDOUT) OUTDD(STDOUTPR) TEXT' //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY //STDOUT DD PATH='/tmp/&SYSUID.-HOSTSAVE.out', // PATHOPTS=(ORDONLY), // PATHDISP=(DELETE,KEEP), // PATHMODE=(SIRUSR,SIWUSR) //STDOUTPR DD SYSOUT=*, // DCB=(LRECL=4000,RECFM=VB) //* //PRERR EXEC PGM=IKJEFT1A, // PARM='OCOPY INDD(STDERR) OUTDD(STDERRPR) TEXT' //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY //STDERR DD PATH='/tmp/&SYSUID.-HOSTSAVE.err', // PATHOPTS=(ORDONLY), // PATHDISP=(DELETE,KEEP), // PATHMODE=(SIRUSR,SIWUSR) //STDERRPR DD SYSOUT=*, // DCB=(LRECL=4000,RECFM=VB) //*