SCP uses SSH under the covers. Your local SCP uses SSH to connect with a partner SCP. From what I have seen, it does spawn a second process on the local side, so it's the same SSH command people would execute for non-SCP work. Multiple processes is cumbersome, and on CMS (OpenVM) is particularly heavy and can be messy. Though I can see why the authors would find the implementation easier that way.
I have never tried switching out what SCP uses for the session layer. It's not clear that you can change SCP's use of SSH. The "command at target" implies that SSH (and SCP) was installed outside of the default command search, in which case the partner SCP must be fully named. Experience with the z/OS SSH package confirms that you can generate your keys on a Unix system (or Linux or CYGWIN). They're stored as plain text. -- R; Thomas Kern <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 02/01/2007 01:54 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> From Thomas Kern <[EMAIL PROTECTED]> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Open SSH on VM Have you tried the scp command from the OpenSSH package? I need secure file copy from CMS more than I need a secure terminal session. But 'ssh target "command to execute at target"' would be nice to execute from CMS. I can deal with generating the public/private keys on one of my Linux svms or on a linux/86 platform. Were you able to use some of the commands from the OpenSSL package, such as to encrypt a data file with some public/private key? /Tom Kern /301-903-2211 On Thu, 1 Feb 2007 12:43:08 -0500, Richard Troth <[EMAIL PROTECTED]> wrote: >Yeah ... we need an SSH client too. (We have a sort-of server, but >that's another story.) > >I tried to build OpenSSL and then OpenSSH on z/OS (USS), but could not >get the ./configure step to behave. In particular, both scripts get >wedged on a shell file descriptor. (Other packages which follow the >standard recipe build pretty well on USS.) Given this wonderful "cradle" > (I think it's an LE thing), you can take binaries from USS and run them >on OpenVM without additional work. Very nice! ... if they'll just >build in the first place. > >The single biggest challenge on OpenVM (compared to USS) is how it >handles fork(). Long story. Not for now. > >We have the z/OS OpenSSH package (in its SMP/E wrapper). SSH to/from >z/OS works just fine. I find that the 'ssh' executable from that runs >directly on OpenVM, but fails when it tries to generate (or collect?) >entropy or some other step in the encryption game. To be specific, if >you enter > >ssh > >it gives you the help, but if you enter > >ssh remotehost > >it ABENDs. I tried replacing the support program that I thought SSH was >after with something that did not ABEND. Didn't help. That was some >time back. > >-- R;
