Launcher failing with rc = 8

[usaajrm]

Launcher failing with rc = 8

Error messages
1
FOTS3001 zsshIcsfMacInit (415): CSFPTRC failed: return code = 8, reason code = 16008

CoZLauncher[E]: myid@myserver target command '<default shell>' ended with RC=255

[dovetail]

Co:Z Launcher invokes the IBM Ported Tools "ssh" command, and this error indicates that the ssh command fails.

Ported Tools seems to be failing in a call to ICSF to initialize MAC support. I looked up the reason code (16008) from CSFPTRC in the ICSF Applications Programmers Guide, and it isn't documented .

My suggestions:

1) review the instructions for setting up ICSF Cipher/Mac support in the IBM Ported Tools User's Guide. Double check that you have the required maintenance for IBM Ported Tools, ICSF, and z/OS. Refer to the latest Ported Tools User's Guide under "Setting up OpenSSH to use ICSF ciphers and MAC algorithms" and the following APARs/PTFS: OA37278 , OA29401, PK86329

2) rerun the failing job with the following option:

//COZCFG DD *
ssh-options=-vvv

this will enable debugging messages for IBM Ported Tools OpenSSH. Of particular interest are the messages related to the status of ICSF. You can post the output here and we will be happy to review.

3) If the above fails, open a PMR with IBM Ported Tools OpenSSH. You should be able to reproduce this problem by entering the following command from a z/OS Unix shell:

ssh -vvv myuser@myhost

( do this from the same z/OS userid that you are running the Co:Z Launcher job under, since the problem may be related to user-specific ssh options or maybe the user's RACF authority)

Note: this will have to be done from TTY telnet, a z/OS SSH shell, or under Co:Z Batch.... the IBM Ported Tools ssh command cannot be used from a TSO OMVS environment

[atrivino]

Team,

I have receiving the following for a single process on an environment which did not receive maintenance recently. Would this be caused by the remote server if zOS is the client.

Message:
FOTS3001 zsshIcsfMacInit (415): CSFPTRC failed: return code = 16, reason code = 4

[coz]

The ICSF Application Programmer's Guide messages and codes for the RC/reason doesn't provide much help:

"ICSF: Your call to an ICSF callable service resulted in an abnormal ending."

I would suggest that you capture a D3 trace of the client (via the -vvv option) and contact IBM for more information. You might also want to check the system log to see if anything was written there at the time of the error.

[dovetail]

According to the ICSF System Programmer's Guide, this RC/Reason will result in an ABEND x'18F'.
If you can find the ABEND, the reason code for this ABEND may help you figure out what is going wrong in ICSF (see x'18F' in Messages and Codes)

Note: IBM Ported Tools OpenSSH is making the ICSF call, not Co:Z SFTP.
If you can't resolve the cause of the ICSF problem, you should probably open a problem with the IBM support center

[Nova]

Today, after a zOS upgrade to 2.1 and changes to ICSF due to a PCI compliance project, the following was seen after doing a test sftp which worked prior to the migration and project:
FOTS3001 zsshIcsfCipherInit (940): CSFPTRC failed: return code = 8, reason code = 16008
The cause was tightening down the screws on crypto resources - probably by the group working on the PCI project.
The following was seen as a resource violation in the ACF2 violation report:
RCRY-CLEARKEY.SYSTOK-SESSION-ONLY ... RC 8
Writting a rule for resource type CRY solved the issue.

This error was only seen when executing batch program cozbatch.
That is, this error was not seen when executing cozsftp from the shell.

[dovetail]

I'm not familiar with this SAF resource name:

RCRY-CLEARKEY.SYSTOK-SESSION-ONLY

have you spelled it exactly right? Is the "RCRY-" prefix an ACF2 artifact?

Are you sure that you are not referring to this? (from our P.T. Quick install guide: https://dovetail.com/docs/pt-quick-inst ... -icsf.html

Note: Starting with ICSF version HCR77A0, the CSF1TRC API used by P.T. OpenSSH will check for the existence of a SAF/RACF resource: CLEARKEY.SYSTOK-SESSION-ONLY CLASS(CRYPTOZ). IBM suggests that you do you not define this specific resource or a matching generic resource. If you do, then you must permit all SSH/SSHD userids READ access.

[Nova]

ACF2 Resurce Rules are 3 letters. RCRY translates to Resource CRYpto.
There's a CLASSMAP record to map this to the RACF equivalent.
Thanks for the quote below becuase that is what is happening. And, it only happens to one batch job (so far) out of many.
Adding the RCRY rule to ALLOW all logonids to use the resource resulted in the job running to completion.
In our case, the rule was written to include all subkeys of CLEARKEY:
$KEY(CLEARKEY) TYPE(CRY)
-.- UID(*) LOG
We'll change LOG to ALLOW in a few weeks .. after allowing some time to check usage reports.
Note: copying the cozsftp command from the script used in batch and pasting to a unix shell on the same host
and executing the command resulted in NO function call for the CSFPTRC resource.
It's amazing what happens when your userid is all powerful. The batch job ran with a service ID with minimal authority...but enough to access the correct keyrings.

[dovetail]

Its a little tricky as to whether CSFPTRC would be called.

You would need to:

- have CiphersSource or MacsSource = ANY or ICSF (this could be done in a user-specific zos_ssh_config file)
- if ANY, ICSF would only be used if the Cipher or Mac that you negotiated for this session was ICSF enabled.
- of course, as you point out, there could be differences in SAF access between the two. But in this case I would expect a failure

(Note: all of this stuff actually happens in IBM Ported Tools OpenSSH, not Co:Z )

[Nova]

Yes, it's definitely only a Ported Tools function.
cozsftp, as we know, is more predictable because the authors must be genii.
No ESM rules needed for coz - the way we like it.