[Contents] [Index]

About This Document >>     Installing SSH Tectia Server for IBM z/OS >>     Using SSH Tectia Server for IBM z/OS >>     Configuring the Server >>     Configuring the Client >>     Authentication >>     Troubleshooting SSH Tectia Server for IBM z/OS >>     Examples of Use >>         Secure File Transfers Using the z/OS Client>>         Secure File Transfers Using Windows and Unix Clients>>         Submitting JCL Jobs over Secure Shell         Debugging SSH Tectia Server for IBM z/OS>>         Example of Distributing Keys >>             Mainframe Server Keys             Remote Server Keys             Mainframe User Keys             Remote User Keys     Man Pages >>     Log Messages >>

Mainframe User Keys

Administrators and other people can use passwords or public-key pairs with a passphrase-protected private key to access remote machines with SSH Tectia clients from a Telnet or Secure Shell session. They can also use public-key pairs with a null passphrase if they want to run the SSH Tectia client programs in JCL.

Mainframe batch users are accounts that represent applications or subsystems, not people. They are set up with public-key pairs with a null passphrase to enable non-interactive access through JCL to remote servers. One key pair is generated for each batch user. If the batch user has a shared home directory, the key is placed in the shared $HOME/.ssh2 directory, otherwise it is copied to the user's home directories on all the LPARs.

When the ssh-keygen2 utility program is used with the -P option, which requests a null passphrase, it can be run from the OMVS shell or in JCL. It must be run under the batch user's user ID in order for the file permissions to be set properly. For more information on the ssh-keygen2 options, see Appendix ssh-keygen2.

The batch user accesses the remote machine using an account created and administered on the remote machine. The remote username may either be the same as the batch user's RACF user ID, or the same but in lower case, or a different username. Several batch users may use the same remote account. One batch user may use separate accounts on one remote machine for different accesses.

Each batch user's public key must be distributed to all the remote accounts it will be accessing. The way the public key is set up differs between SSH Tectia and OpenSSH. The ssh-userkeygendist2.sh script must be told which type of server the remote machine has. The server must be running when ssh-userkeygendist2.sh is run.

ssh-userkeygendist2.sh uses password authentication for this initial access to the remote server. The password for the remote account must be entered in a file. The filename is entered as one of the options in the ssh-userkeygendist2.sh command.

The other options needed on the ssh-userkeygendist2.sh command line are the remote account username, the remote host DNS name or IP address, and the type of the remote Secure server (SSH Tectia Server on Unix, SSH Tectia Server on Windows, SSH Tectia Server for IBM z/OS on mainframe, or OpenSSH on Unix).

Example 1: Public-key upload to OpenSSH server.

This command creates a 512-bit DSA key and uploads it to the OpenSSH server including the necessary conversions. Public-key upload uses "password-from-file" for authentication.

> ./ssh-userkeygendist2.sh -u testuser -O -P -p /home/userid/passwd_file \
   -d -t dsa -b 512 -a open_server.company.com

Setting up password-from-file:

> touch /home/userid/passwd_file
> chmod 600 /home/userid/passwd_file
> vi /home/userid/passwd_file                (or some other editor)

The format of the passwd_file is just a one line containing the password:

MyPasS

Example 2: Public key upload to SSH Tectia Server on Unix.

This command works against 4.x and 5.x SSH Tectia Server on Unix, using the 4.x-style authorization file. The command uses an existing public key instead of creating a new one.

> ./ssh-userkeygendist2.sh -u userid -S -p /home/userid/passwd_file \
   -f /home/userid/.ssh2/id_rsa_1024_a.pub tectia_server.company.com

Example 3: Public-key distribution to multiple hosts.

This example distributes a public key to several remote hosts automatically. Individual user names can be defined for each server. Server type (SSH Tectia Windows, SSH Tectia z/OS, OpenSSH) needs to be defined with the flags: -W, -Z, or -O.

In this example you can find four server "blocks":

• -O -u userid host1 (for connecting to OpenSSH host1)
• -O -u userid2 host2 (for connecting OpenSSH host2)
• -W -u userid host3 (for connecting to SSH Tectia Windows host3)
• -Z -u mf_userid host4 (for connecting to SSH Tectia z/OS host4)

Note that only one password file can be defined. This means that all the hosts must have same password.

> ./ssh-userkeygendist2.sh -P -d -p /home/userid/passwd_file \
   -t rsa -b 1024 -a \
   -O -u userid host1 \
   -O -u userid2 host2 \
   -W -u userid host3 \
   -Z -u mf_id host4

Example 4: Multiple hosts using host lists.

This example distributes a public key to several hosts using host lists. This is perhaps the most convenient way to use this tool in large environments. This example uses an existing RSA key pair.

The host lists need to be grouped so that all SSH Tectia Unix, SSH Tectia Windows, SSH Tectia z/OS, and OpenSSH hosts are in different host files, for example tectiaunix_hostlist, tectiazos_hostlist, openssh_hostlist, each hostlist defined in the following way:

userid1/server1 userid2/server2 userid3/server3

> ./ssh-userkeygendist2.sh_new -f /home/userid/.ssh2/id_rsa_1024_a.pub \
   -a -v -p /home/userid/passwd_file \
   -S -H tectiaunix_hostlist \
   -Z -H tectiazos_hostlist \
   -O -H openssh_hostlist