Launcher failing with rc = 8

Discussion of the Co:Z Co-Processing Toolkit for z/OS
Post Reply
usaajrm
Posts: 80
Joined: Tue Feb 06, 2007 3:46 pm

Launcher failing with rc = 8

Post by usaajrm » Mon Oct 08, 2012 4:30 pm

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
Site Admin
Posts: 1791
Joined: Thu Jul 29, 2004 12:12 pm

Re: Launcher failing with rc = 8

Post by dovetail » Tue Oct 09, 2012 10:11 am

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
Posts: 16
Joined: Wed Jul 13, 2011 9:28 am

Re: Launcher failing with rc = 8

Post by atrivino » Mon Feb 10, 2014 5:59 pm

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

SteveGoetze
Posts: 376
Joined: Fri Jul 30, 2004 5:29 pm

Re: Launcher failing with rc = 8

Post by SteveGoetze » Tue Feb 11, 2014 8:35 am

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
Site Admin
Posts: 1791
Joined: Thu Jul 29, 2004 12:12 pm

Re: Launcher failing with rc = 8

Post by dovetail » Wed Feb 12, 2014 2:52 pm

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
Posts: 6
Joined: Sun Jan 03, 2010 3:28 pm

Re: Launcher failing with rc = 8

Post by Nova » Wed Apr 22, 2015 7:59 pm

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
Site Admin
Posts: 1791
Joined: Thu Jul 29, 2004 12:12 pm

Re: Launcher failing with rc = 8

Post by dovetail » Thu Apr 23, 2015 3:11 pm

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
Posts: 6
Joined: Sun Jan 03, 2010 3:28 pm

Re: Launcher failing with rc = 8

Post by Nova » Thu Apr 23, 2015 3:47 pm

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
Site Admin
Posts: 1791
Joined: Thu Jul 29, 2004 12:12 pm

Re: Launcher failing with rc = 8

Post by dovetail » Thu Apr 23, 2015 5:41 pm

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
Posts: 6
Joined: Sun Jan 03, 2010 3:28 pm

Re: Launcher failing with rc = 8

Post by Nova » Thu Apr 23, 2015 6:30 pm

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.

Post Reply