Distributing 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 run 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-keydist2 script must
be told which type of server the remote machine has. The server must be
running when ssh-keydist2 is run.
ssh-keydist2 uses password authentication for this
initial access to the remote server. The password for the remote account
must be entered in a dataset or in a file. See Sections
File and
Dataset for instructions.
The filename is entered as one of the options in the
ssh-keydist2 command.
The other options needed on the ssh-keydist2 command
line are the remote account username, the remote host DNS name or IP
address, and the type of the remote Secure Shell server (SSH Tectia Server on Unix,
SSH Tectia Server on Windows, SSH Tectia Server for IBM z/OS on mainframe, or OpenSSH on Unix).
Password from File
To set up password-from-file authentication:
- Create a file, for example
/home/userid/passwd_file.
- Make sure the file is readable only by the user that created it:
> chmod 600 /home/userid/passwd_file
- Edit the file with your favorite text editor to contain one line
with your password on the remote system, for example:
Password from Dataset
To set up password-from-dataset authentication:
- Allocate a dataset or a dataset member, for example:
//'USERID.PASSWD'
- Make sure that the dataset is accessible only by the correct
UserID.
- Edit the password dataset to contain your password on the remote
system. The format of the password dataset is one line containing only
the password. For example:
Examples of Distributing User Keys
The following examples illustrate using ssh-keydist2
for distributing user keys.
Caution: When ssh-keydist2 is run with the -a
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.
To be able to verify the keys, you should use the plain host
key storage format. See Section Authenticating Remote Server Hosts for more information.
Example 1: Public-Key Upload to Unix OpenSSH Server from USS Shell
This command creates a 1024-bit DSA key and uploads it to a Unix server
running OpenSSH, including the necessary conversions. Public-key upload
uses password-from-dataset for authentication:
> ./ssh-keydist2 -u testuser -O -P -p /home/userid/passwd_file \
-d -t dsa -b 1024 -a open_server.example.com
Example 2: Public-Key Upload to Unix OpenSSH Server Using JCL
This example KEYDIST from SAMPLIB presents a JCL
script that does the same steps as the USS command in Example 1 above:
//KEYDIST EXEC PGM=IKJEFT1A,
// REGION=0M
//SYSTSPRT DD SYSOUT=*
//STDOUT DD PATH='/tmp/&SYSUID.-KEYDIST.out',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRUSR,SIWUSR)
//STDERR DD PATH='/tmp/&SYSUID.-KEYDIST.err',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRUSR,SIWUSR)
//STDENV DD DSN=&SYSUID..SSZ.SRVR542.PARMLIB(SSHENV),
// DISP=SHR
//SYSTSIN DD *
BPXBATCH SH /usr/lpp/ssh2/bin/ssh-keydist2.sh +
-t rsa -b 1024 -P +
-u userid -p "//'USERID.PASSWD'" +
-a -A /tmp/my_log_file +
-O host1.example.com
/*
//*
//PROUT EXEC PGM=IKJEFT1A,
// PARM='OCOPY INDD(STDOUT) OUTDD(STDOUTPR) TEXT'
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//STDOUT DD PATH='/tmp/&SYSUID.-KEYDIST.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.-KEYDIST.err',
// PATHOPTS=(ORDONLY),
// PATHDISP=(DELETE,KEEP),
// PATHMODE=(SIRUSR,SIWUSR)
//STDERRPR DD SYSOUT=*,
// DCB=(LRECL=4000,RECFM=VB)
//*
|
Example 3: Public-Key Upload to SSH Tectia Server on Unix from USS Shell
This command works against SSH Tectia Server 4.x and 5.x on Unix, using the
4.x-style authorization file. The command uses an existing public key
instead of creating a new one:
> ./ssh-keydist2 -u userid -S -p /home/userid/passwd_file \
-f /home/userid/.ssh2/id_rsa_1024_a.pub tectia_server.example.com
Example 4: Public-Key Distribution to Multiple Hosts from USS Shell
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 the same password.
The command is as follows:
> ./ssh-keydist2 -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 5: Public-Key Distribution to Multiple Hosts Using Host Lists from USS Shell
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 host list defined in the following way:
userid1/host1.example.com
userid2/host2.example.com
userid3/host3.example.com
|
Note that only one password file can be defined. This means that all the
hosts must have the same password.
The command is as follows:
> ./ssh-keydist2_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
