|
I hope I'm sending this to the right group. I'm subscribed to this group
as well as the HTTPAPI group and the RPGLE group, I'm not sure if this is a
message for this group or one of those. I think this is the right group
though.
We went live with a process a few weeks ago that does SFTP to a site. We
create XML files and send them both interactively (HTTPS) and batch (SFTP)
using both HTTPAPI and CGIDEV2. The SFTP process we have to "zip" and
password protect the files before sending.
I have two issues with the batch SFTP process, one being, I'm not sure this
is setup properly to begin with as we have IP addresses in our host tables,
the other issue being, one of the sites we should be able to connect to is
getting an error.
The setup: The only way we were ever able to connect to the other system
was to have the IP addresses set up in Work with TCP/IP host table entries
(CFGTCP option 10) screens. I understand that we shouldn't need to have an
IP address hard coded there, but we've never been able to get SFTP to work
without it. We actually have two or three different SFTP transmissions for
different projects, and they're all set up that way.
Regarding the site that's not working:
We currently have three IP addresses set up with three URLs in the host
table entrees for this particular project. Two of them are working fine,
the Beta site and the secondary Live URL. At some point I discovered that
the primary Live URL was never set up at all, and that we had been sending
all our live transmissions via the secondary live site. I tried to set up
the primary URL in the host table entry, but it's not working. It should
work using the same SSH key (which my operations manager set up) and the
same User as the secondary site which has been working.
The IP address/URL combination is set up the same way on the host table
entry.
The message I'm getting at the bottom of the log is: Write failed: There
is no process to read data written to a pipe.
Here's the last page of what I'm seeing leading to that message, I blocked
out the Host URL and User ID:
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 129/256
debug1: bits set: 1013/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/XXXXXX/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug3: check_host_in_hostfile: filename /home/XXXXXX/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host 'xxxx.xxxx.xxx' is known and matches the RSA host k
debug1: Found key in /home/XXXXXX/.ssh/known_hosts:3
debug1: bits set: 1067/2048
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
Write failed: There is no process to read data written to a pipe.
debug1: Calling cleanup 0x20013a74(0x0)
Prior to that point, the "good" run from the alternate URL looks almost the
same.
They both say that a connection is established through port 22.
This may be irrelevant, but I did see one difference in the logs on page 1.
The failed run says:
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.7p1+sft
The good run on the other url says:
debug1: Remote protocol version 1.99, remote software version
OpenSSH_4.7p1+sf
Not sure why the two remote sites have different version of OpenSSH or if
that matters at all.
I'm guessing probably not, but just thought I'd mention it.
Also not sure if this would help, but here's the "good" run on the
alternate URL where it gets past that point.
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 140/256
debug1: bits set: 1000/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/XXXXXX/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/XXXXXX/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'xxxxxxxALT.xxxxxxx.xxx' is known and matches the RSA host
debug1: Found key in /home/XXXXXX/.ssh/known_hosts:1
debug1: bits set: 991/2048
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue:
publickey,password,keyboard-interac
debug3: start over, passed a different list
publickey,password,keyboard-intera
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
....
It was my operations manager that handled all the setup of the SSH keys.
If it helps, here's the code from my CL program, which works for the
"alternate" and Beta sites but not for this other site.
CHGVAR VAR(&CMD) VALUE('sftp -vvv -b +
/home/orbital/opzipput.txt' +
*BCAT &PDSC5A)
CALL PGM(QP2SHELL) PARM('/QOpenSys/usr/bin/-sh' +
'-c' &CMD)
Any help would be appreciated in identifying:
(1) Why I'm getting the "Write failed: There is no process to read data
written to a pipe."
(2) How to set it up without IP addresses hardcoded.
Our online HTTPS process, by the way, is working fine... Without IP
addresses hardcoded in the host tables.
We've only been unable to get SFTP working without IP addresses.
Charlie
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
