Classification: HCL Internal Yes it is . I do this many times daily.
There are 2 stages to the authentication. Server and User. For Server Authentication, all that is needed is the public key of the foreign host in the /etc/ssh./known_hosts For the sake of discussion, I am going to assusme this is MF--.foreign host. You need to install the foreign host public key (for whatever user on the foreign host) in /&uid/.ssh/authorized_keys. The job(s) will run with a ESM id of &UID. CoZ makes things much easier than the zOS version of OpenSSH, but is not required. The IBM code can handle everything just fine. For more info see: http://www.dovetail.com/webinars.html Towards the bottom of the page you will see: " IBM Ported Tools for z/OS: OpenSSH - Key Authentication" Although Dovetail produced the content, it is non-CoZ dependent. Disclaimer. I have no affiliation with Dovetail except as a user of their fine products. HTH, -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Wendell Lovewell Sent: Thursday, October 15, 2020 7:37 PM To: [email protected] Subject: Batch SFTP without client keys or USS files? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Is it possible to code a proc that would invoke SFTP to transfer a file to or from a non-z/OS ftp server using only that server's public key and a userid/password combination like you would use for FTP or FTPS? I need to distribute this outside our company, so using CO:Z isn't an option. Adding keys to the server for the clients is not either. And modifying USS files like /etc/ssh/config or even ~/.ssh/anything is probably also off limits. I might be able to get away with stashing something in /tmp, but even that might be a problem. I can (since I have to) assume z/OS 2.2 or later for OpenSSH availability. I was able to do this for FTPS by distributing the FTP server's public key as a .PEM file & installing it into RACF, then adding it to a keyring. But so far with SFTP, I'm stumped. Has anyone tried this? TIA, Wendell fwiw, here is the FTPS proc: //*------------------------------------------------------------------- //* TERSE a file & FTP it //*------------------------------------------------------------------- //FTPSTRS PROC ZOSFILE=, // FTPFILE=, // OUTCLS=*, // TMPHLQ=&SYSUID, // TRSDISP=(NEW,PASS), // KEYOWNR=TCPIP, // KEYRING=FTPS.KEYRING //* //EXP EXPORT SYMLIST=* // SET FTPFID=&FTPFILE // SET FTPOWN=&KEYOWNR // SET FTPKEY=&KEYRING //* //*------------------------------------------------------------------- //TERSE EXEC PGM=TRSMAIN,PARM=PACK //SYSPRINT DD SYSOUT=&OUTCLS //INFILE DD DISP=SHR,DSN=&ZOSFILE //OUTFILE DD DSN=&TMPHLQ..TEMP.TRS, // DISP=(&TRSDISP.), // RECFM=FB,BLKSIZE=0,LRECL=1024, // LIKE=&ZOSFILE //*------------------------------------------------------------------- //FTPS EXEC PGM=FTP,REGION=4M,COND=(0,LT), // PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV")/ftp.server.com 21 -e') //STDENV DD * GSK_PROTOCOL_TLSV1_2=ON //SYSFTPD DD *,SYMBOLS=(JCLONLY) CLIENTERRCODES EXTENDED EPSV4 TRUE EXTENSIONS AUTH_TLS FWFRIENDLY TRUE KEYRING &FTPOWN/&FTPRING PASSIVEIGNOREADDR TRUE SECUREIMPLICITZOS FALSE SECURE_FTP REQUIRED SECURE_MECHANISM TLS SECURE_DATACONN PRIVATE SECURE_CTRLCONN PRIVATE SECURE_HOSTNAME REQUIRED TLSMECHANISM FTP TLSRFCLEVEL RFC4217 //* TRACE //TRSFILE DD DISP=SHR,DSN=*.TERSE.OUTFILE //OUTPUT DD SYSOUT=&OUTCLS //INPUT DD *,SYMBOLS=(JCLONLY) ftpuser ftppwd sendsite cd /somedir BINARY PUT //DD:TRSFILE &FTPFID QUIT //* // PEND ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
