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?
z/OS 913-38 "not authorized" error with BPXBATCH
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:
Otherwise, you will be able to connect, but not authenticate with the remote server, since the "SSH_ASKPASS" program will not be found.
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
z/OS 913-38 with COZBATCH
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
Thanks also for the pointer on ASKPASS.
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
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].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.
Thanks also for the pointer on ASKPASS.
Progress!
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.
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.