batch sftp fails on password

[smalony]

Hello All,

I am having a problem with the batch sftp client.

When I ssh into our mainframe and sftp to pridusr@cdtspri100d I get the password prompt and type in the password and all i ok.

When I do that through the batch, the remote server does not accept the password.
I have looked at the obvious things like case, and nums off on the mvs file, but everything is set ok. If I use the same file to connect to one of my zlinux server, it works.

I have turned on the -vv option and I am seeing the client and server trying to connect.

I am at a lost. Any ideas out there?

Here is the output that I am receiving:

CoZBatch[N]: Copyright (C) 2005-2009 Dovetailed Technologies LLC. All rights reserved.
CoZBatch[N]: version 1.10.1 2011-11-07
CoZBatch: executing progname=login-shell="-/bin/sh"
Co:Z SFTP version: 1.10.1 (5.0p1) 2011-11-07
Copyright (C) Dovetailed Technologies, LLC. 2011. All rights reserved.
OpenSSH_5.0p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: zsshSmfSetConnSmfStatus: SMF status is 0
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to cdtspri100d [162.44.114.170] port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: fd 4 clearing O_NONBLOCK
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /u/g304227/.ssh/id_rsa type 1
debug1: identity file /u/g304227/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received


Here is the JCL that I am running:
//RUNSFTP EXEC PGM=COZBATCH
//STEPLIB DD DISP=SHR,DSN=SYS3.COZ.LOADLIB
//INPUT DD DISP=SHR,DSN=IMS.PARMLIB(IMSMS001)
//STDIN DD *
# Customize these ... "
coz_bin="/usr/lpp/vendor/coz/bin"
ruser="pridusr"
server="cdtspri100d"
servercp="ISO8859-1"
# servercp="IBM-1047"
rfile="ims.sortcards"
# These can be used to read the ssh password from a (secured) dataset
# if you don't want to setup public/private keypairs ¡
export PASSWD_DSN='//IMS.TAG.JCLLIB(N8PASSW)'
export SSH_ASKPASS=$coz_bin/read_passwd_dsn.sh
ssh_opts="-oBatchMode=no" # allows ssh to use SSH_ASKPASS program
ssh_opts="$ssh_opts -oConnectTimeout=60"
ssh_opts="$ssh_opts -oServerAliveInterval=60"
ssh_opts="$ssh_opts -oStrictHostKeyChecking=no" # accept initial host
ssh_opts="$ssh_opts -vv" # verbose
# Invoke the Co:Z sftp client with an in-line batch of commands
# that downloads a remote file to a local DD.
# Note that "-oBatchMode=no" must be specified before "-b"
# since ssh opts are first-sticky
$coz_bin/cozsftp $ssh_opts -b- $ruser@$server <<EOB
lzopts mode=text,servercp=$servercp
lzopts
put //DD:INPUT $rfile
EOB

Any help would be greatly appreciated.

Thanks
Steve Malony
IMS Health

[smalony]

Hello All,

OK, I have gotten it down to the password. The password for the server is devl_net2. The batch process does not like the underscore. When I remove that and change the password for that user on the remote server, the batch transfer successfully completes.

Is there a way to code the _ charater in the dataset so that cozsftp will recognize it?

Thanks
Steve

[dovetail]

This is curious indeed. It seems unbelievable that an underscore would cause a problem, but you are seeing it. I will do some testing here to see if I can reproduce.

For what its worth, the actual password authentication is done by IBM Ported Tools OpenSSH. What the Co:Z sample script does is to set up an "SSH_ASKPASS" script that provides it the password.

I tried to recreate your problem, without success. Following is what I did; please reproduce these tests on your system:

First, I tested read_passwd_dsn.sh, and it works fine for me:

Code: Select all

> # from an interactive z/OS Unix shell
> export PASSWD_DSN='//KIRK.COZ.SAMPJCL(PW)'    
> /usr/lpp/coz/bin/read_passwd_dsn.sh 
devl_net2

Next, I tested that I could interactively supply the password using the IBM Ported Tools for z/OS ssh client. To do this you will need to log into a z/OS shell under ssh (the IBM ssh client won't work under TSO OMVS).

Code: Select all

> # from a z/OS Unix shell login under ssh
> ssh kirk@linux1.dovetail.com
kirk@linux1.dovetail.com's password: (I typed devl_net2)
...
Last login: Fri Jun 29 06:39:05 2012 from zosdtl

Finally, I verified that I could run the "RUNSFTP" sample that you are using with this password in my PASSWD_DSN, and it worked fine.

[dovetail]

Perhaps there is a mismatch in your character encoding....

- what encoding are you using in your TN3270 emulator?
For IBM-037 and IBM-1047, the underscore character is X'6D'. Check the hex value in your dataset.
Also, make sure that your dataset only contains the password and that the remainder of the record is spaces.

- what character encoding are you using under z/OS Unix?
- what is your "LANG" environment variable set to? Are you setting any "LC_*" variables?
- add a line: "env" to the beginning of your Co:Z BATCH STDIN script to dump your environment variables for the batch job.

[smalony]

Hello Dovetail,

I am totally confused now. I switched the servercp from ISO8859-1 to UTF-8 and the batch sftp worked. I then ran an ICONV to convert the password file from IBM-1047 to both ISO8859-1 and UTF-8. I compared the two files and they were the same. I then ran the batch sftp with the servercp=ISO8859-1 expecting it to fail, and it worked. Now I can't get it to fail. I do not now believe that it was the underscore character.

Now I am trying to determine if something got update in the .ssh directory like known_hosts to see if the first days I was running this, it was not getting updated, and once I logged in via putty to test this, it updated my file and now batch sftp is working.

Thanks for looking at this for me.

If I find more with my testing, I will updat thsi.

Thanks
Steve

[dovetail]

Its a Heisenbug

I doubt that logging in to z/OS with PuTTY would have anything to do with problems that the z/OS client is having. known_hosts is a client-only SSH file.