z/OS 913-38 "not authorized" error with BPXBATCH

Discussion of the COZBATCH utility for z/OS
Post Reply
Randy
Posts: 16
Joined: Thu Jul 08, 2010 1:36 pm

z/OS 913-38 "not authorized" error with BPXBATCH

Post by Randy »

sshd demon is running per Ported Tools manual.
I am trying to run BPXBATCH as follows:
//STDIN DD *
# Customize these ...
coz_bin="/usr/lpp/coz/bin"
remoteuser="VRH0"
server="LPTEST"
servercp="ISO8859-1"
# Using a password from an MVS dataset
export PASSWD_DSN='//VRH0.JCL.CNTL(SITE)'
export SSH_ASKPASS=read_passwd_dsn.sh
export DISPLAY=none

ssh_opts="-oBatchMode=no" # allows ssh to use SSH_ASKPASS program
ssh_opts="$ssh_opts -oConnectTimeout=60"
ssh_opts="$ssh_opts -oServerAliveInterval=60"
ssh_opts="$ssh_opts -oStrictHostKeyChecking=no" # accept initial host ke
$coz_bin/cozsftp $ssh_opts -b- $remoteuser@$server <<EOB
lzopts -a
EOB
/*
The job terminates with IEC150I 913-38 for four datasets:
SYS1.COZ.LOADLIB (home of BPXBATCH)
TCPIP.Z19.TCPPARMS(TCPDATA)
TCPIP.STANDARD.TCPXLBIN
TCPIP.HOSTS.SITEINFO

We have double checked the security settings in the Ported Tools "Daemon" section (translating form RACF to TopSecret), but have obviously missed something.

Suggestions?
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Post by dovetail »

I assume that you meant to say COZBATCH, rather than BPXBATCH?

What you have posted looks like the shell script script part the Co:Z SFTP client sample JCL, which runs the Co:Z SFTP client (the z/OS Unix "cozsftp" command) under COZBATCH (a batch utility used to simplify invoking a z/OS Unix shell in batch).

If this is the case, the IBM Ported Tools SSH "Daemon" is not used for this job, since this is a client. The cozsftp command uses the IBM Ported Tools "ssh" client command to connect to the remote server. You don't even need to have the IBM Ported Tools sshd daemon process running to use the client.

The IBM Ported Tools ssh client command would require read access to the TCPIP datasets, since it uses the stack to open a socket. If COZBATCH is in SYS1.COZ.LOADLIB, you would require access to load the module.

One other observation: if the coz_bin directory is not in the default path for this user's login shell, you will need to change one line to something like this:

Code: Select all

export SSH_ASKPASS=$coz_bin/read_passwd_dsn.sh
Otherwise, you will be able to connect, but not authenticate with the remote server, since the "SSH_ASKPASS" program will not be found.
Randy
Posts: 16
Joined: Thu Jul 08, 2010 1:36 pm

z/OS 913-38 with COZBATCH

Post by Randy »

Yes, COZBATCH! Also, yes it is the sample shell script modified to get the password and only list the options. I'm trying to prove program execution before getting into actually testing the FTP of an MVS dataset to a UNIX host.

Thanks for the background info on not needing the daemon, one less thing to worry about. :)

We figured out that ut was the spawned tasks getting the 913-38s but can't figure out how to determine what needs to be fixed. Your comment
The IBM Ported Tools ssh client command would require read access to the TCPIP datasets, since it uses the stack to open a socket. If COZBATCH is in SYS1.COZ.LOADLIB, you would require access to load the module.
seems to point to that also. What is the "ssh client" that has to be authorized? I can find security definition steps for the daemon but not the client [ref: Ported Tools for z/OS User's Guide].

Thanks also for the pointer on ASKPASS.
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Post by dovetail »

The IBM Ported Tools "ssh" command (the client) doesn't require any special authorization that I'm aware of, but it does require access to the IP stack.

If you are still having problems, it would be helpful if you could post a complete job log (after scrubbing any confidential info).
Randy
Posts: 16
Joined: Thu Jul 08, 2010 1:36 pm

Post by Randy »

Progress! :D

The 913-38s were caused by BPXROOT not having sufficient authority in Top Secret. We had to look at The Top Secret log to figure it out, we were focusing on the inscrutable BPXAS.

Now that the client will start up (I've reached the "Read from socket failed" point) the next step is to get a OpenSSH Test Server running and actually logon and trade data.
Post Reply