cozsftp batch errors SafSshAgent FOTS1373

[astallerk]

Attempting to invoke cozsftp in batch (JCL posted below). UID X is attempting to invoke the RACF DCERT of UID Y.
UID Y has successfully logged on to target server using RSA key authentication interactively. i.e. RSA key pairs and server keys have been properly exchanged.

I believe I have provided appropriate RACF permissions for UID X to access keyring/certificate info for UID Y.

Any ideas what I am doing wrong? (z/OS 2.1).

SYSOUT:

CoZBatchÝN¨: Copyright (C) 2005-2013 Dovetailed Technologies LLC. All rights re
CoZBatchÝN¨: version 3.1.2 2015-08-13
CoZBatchÝI¨: executing progname=login-shell="-/bin/sh"
SafSshAgentÝE¨: Keyring: 'XXXXXXXX-RING' was not found
SpawnSafSshAgentÝE¨: Timeout waiting for SSH_AUTH_SOCK creation
Co:Z SFTP version: 3.1.2 (5.0p1) 2015-08-13
Copyright (C) Dovetailed Technologies, LLC. 2008-2014. All rights reserved.
FOTS1373 Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Ý75.602¨ Connection closed
CoZBatchÝI¨: returning rc=exitcode=255



JCL:

//SFTP JOB (D3523,40134),'B BILLIOT',CLASS=M,
// MSGCLASS=X,REGION=80M,
//* TYPRUN=SCAN,
// NOTIFY=&SYSUID
//*
// EXPORT SYMLIST=*
//*
// SET INFILE=IBLD.ETECUNIX.INPUT
// SET DIR='/apps/etech/data'
//*
//*********************************************************************
//*
//* Batch job to run the Co:Z SFTP client with RACF certificate
//* authentication.
//*
//* Tailor the proc and job for your installation:
//* 1.) Modify the Job card per your installation's requirements
//* 2.) Modify the JOBLIB card to point to the LOADLIB containing
//* COZBATCH.
//* 3.) Customize the shell script below, and the //DOWNLOAD DD
//*
//* NOTE: See SFTPPROC and SFTPSAMP for a more convenient way to do
//* this.
//*********************************************************************
//*
//RUNSFTPK EXEC PGM=COZBATCH,REGION=64M
//STEPLIB DD DISP=SHR,DSN=SYS1.COZ.LOADLIB
//STDIN DD *,SYMBOLS=JCLONLY

# Customize these ...
coz_bin="/usr/lpp/coz/bin"
ruser="etecprod"
server="etech-prd.kbm1.loc"
servercp="ISO8859-1"

ssh_opts="-oConnectTimeout=60"
ssh_opts="$ssh_opts -oServerAliveInterval=60"
ssh_opts="$ssh_opts -oStrictHostKeyChecking=no" # accept initial host ke

# Invoke the Co:Z sftp client with an in-line batch of commands
# that downloads a remote file to a local DD.
# Note that "-k MY-RING" will cause cozsftp to use the Co:Z
# saf-ssh-agent to authenticate the ssh client using the user's
# RACF Digital Certificate in MY-RING

$coz_bin/cozsftp $ssh_opts \
-k XXXXXXXX-RING:XXXXXXXX \
-b- $ruser@$server <<EOB
lzopts mode=text,servercp=$servercp
CD &DIR
put //DD:DOWNLOAD &INFILE
EOB

//DOWNLOAD DD DISP=SHR,DSN=&INFILE

[astallerk]

Take 2: I eliminated the need to have another user access this certificate and I am using the certificate owner's ID. I have narrowed this down to the key ring specification.

command line:

sftp -v -oIdentityKeyRingLabel="XXXXXXXX/XXXXXXXX-RING:XXXXXXXX" XXXXXXXX@remote host

...snippage
debug1: Trying private key 'XXXXXXXX/XXXXXXXX-RING:XXXXXXXX'
FOTS2915 zsshGetKeyFromRing: gsk_open_keyring on 'XXXXXXXX/XXXXXXXX-RING:XXXXXXXX' failed (53817406). Database name is invalid.

I have verified the key ring/label/connect id exists and I believe I have correctly exchanged the public/private key pairs.
Other syntax tried: 'XXXXXXXX/XXXXXXXX-RING'
'XXXXXXXX/XXXXXXXX-RING XXXXXXXX'
'* XXXXXXXXX'

Is there some other syntax?
IS some additonal facility or rule required.

[astallerk]

Finally got it to work using the virtual keyring:

/cozsftp -k "XXXXXXX/*:XXXXXXXX"

[dovetail]

Sorry I missed your question earlier; glad you got it working.

The difference is probably more about using "-k" rather than "-oIdentityKeyRingLabel"

The former is how you specify to use the Co:Z SAF SSH Agent. This is the best way, since it doesn't require that the user have authority to read the public key and therefore it will work with CERTS that have the private key stored in ICSF.

The latter is the syntax used for the Keyring support built into IBM Ported Tools OpenSSH - this doesn't support the ":" syntax between the ring and the label and requires that you use a space. It also requires (prior to release 1.3) that you have literal double-quotes around the whole value.
This also doesn't work with private keys stored in ICSF.

So, you can probably use -k with the actual name of the key ring rather than using "*" to mean the virtual key ring. Which ever way you prefer.
Another cause of your issue with using -k is that, in your final working example, you are specifying a prefix with the USERID/ whose virtual key ring should be used.

So, lets say that you have these users/keyrings:labels :

USER1/RING1:LABEL1
USER1/RING2:LABEL2
USER3/RING3:LABEL3

If you are using the -k syntax and you run under USER1, you can access the second above with any of:
USER1/RING2:LABEL2
USER1/*:LABEL2
RING2:LABEL2
*:LABEL2

and, if LABEL2 is the "default" label in the key ring, then you can leave off ":LABEL2" everywhere