Password authentication with special characters

[Jadon]

Dear Dovetailed,

We are submitting a batch job which leverages the sample proc to call COZBATCH and open a shell in USS to run the cozsftp bin via the shell scripts. This batch job is connecting to a Windows server environment which requires very complex passwords using many special characters.
An example of one of the passwords to the test environment is: g*5<#D!Qyh^*kn/7r

This batch job when using one of these passwords with special characters receives a:
FOTS1373 Permission denied (password,keyboard-interactive).
Ý91.120¨ Connection closed

We then tried three additional scenarios:

Scenario #1:
We SSH into a z/OS lpar with putty and launch the cozsftp client interactively. Using the same userid, password, and destination we are able to connect to this remote Windows server and login without issue.

Scenario #2:
Using WinSCP Windows client GUI on a workstation in the same subnet, we enter the same userid, password, and destination and are able to connect to this remote Windows server as well without issue.

Scenario #3:
We run the same JCL except use a password that is only alphanumeric and mixed case and does not contain these special characters. This job runs fine and there are no issues. The password is out of the same password PDS/E as the complex special character one we tried and which failed.

This behavior leads us to believe something is not liking the special characters when run from batch, i.e. < or ^ or /

We suspect there is an issue in the read_passwd_dsn.sh script. We tried several alterations of this script including different parameters for the fromdsn binary and the Unix sed command. We thought it may be a codepage issue or that the special characters were getting interpreted via variable expansion.

The JCL is below:
//USERIDCZ JOB (XXXXXX),
// 'XXXXXXXX',
// NOTIFY=&SYSUID,
// CLASS=Y,MSGCLASS=2
//SFTPPUT EXEC PROC=SFTPPROC
//SFTPIN DD *
pwdsn="USERID.SOME.DSN.PW.FILE"
user=DOMAIN+USERID
host=somehostname.company.com
sftp_opts="$sftp_opts -oPubkeyAuthentication=no"
sftp_opts="$sftp_opts -oStrictHostKeyChecking=no"
sftp_opts="$sftp_opts -oUserKnownHostsFile=/dev/null"
# sftp_opts="$sftp_opts -oUserKnownHostsFile=/u/USERID/.ssh/known_hosts"
#
# ------------- Start of SFTP command block -------------
. $script_dir/sftp_connect.sh << EOB
lzopts mode=binary,loglevel=T
ls -al
pwd
quit

Below is the proc we are calling:
//EXSFTP PROC ARGS=, < Ý-L<log_opt>¨
// LIBRARY='HLQ.COZ.LOADLIB', < STEPLIB FOR COZBATCH
// SFTPIND='HLQ.COZ.CONFIG(SFTPIND)', < Installation defaults
// REGSIZE='64M', < Execution region size
// LEPARM=''
//RUNSFTP EXEC PGM=COZBATCH,REGION=&REGSIZE,
// PARM='&LEPARM/&ARGS'
//STEPLIB DD DSN=&LIBRARY,DISP=SHR
//STDIN DD DSN=&SFTPIND,DISP=SHR
// DD DDNAME=SFTPIN
//SFTPIN DD DUMMY
//*
// PEND

The SFTPIND options found in HLQ.COZ.CONFIG(SFTPIND) are:
cozbin_dir="/x/x/coz/bin"
script_dir="/x/x/coz/samples/sftp_batch"
sftp_opts=""
sftp_opts="$sftp_opts -oConnectTimeout=60"
sftp_opts="$sftp_opts -oServerAliveInterval=60"
sftp_opts="$sftp_opts -oNumberOfPasswordPrompts=1"

The job run produces the following sysout:
CoZBatchÝN¨: Copyright (C) 2005-2013 Dovetailed Technologies LLC. All rights reserved.
CoZBatchÝN¨: version 3.1.1 2015-07-02
CoZBatchÝI¨: executing progname=login-shell="-/bin/sh"
Unix A/S size is 76.9765625MB; max A/S size is 2048MB
Connect using SSH_ASKPASS, password will be read from USERID.SOME.DSN.PW.FILE...
Executing: /x/x/coz/bin/cozsftp -oBatchMode=no -oConnectTimeout=60 -oServerAliveInterval=60 -oNumberOfPasswordPromp
ts=1 -oPubkeyAuthentication=no -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -b- 'DOMAIN+USERID@somehostname.company.com'
Co:Z SFTP version: 3.1.1 (5.0p1) 2015-07-02
Copyright (C) Dovetailed Technologies, LLC. 2008-2014. All rights reserved.
FOTS2274 Warning: Permanently added 'xxxxxxxxxxxxx' (RSA) to the list of known hosts.

/x/x/coz/bin/read_passwd_dsn.sh prompt: "DOMAIN+USERID@somehostname.company.com's password: "
fromdsn(USERID.SOME.DSN.PW.FILE)ÝN¨: 1 records/80 bytes read; 17 bytes written in 0.001 seconds (16.602 KBytes/sec).
FOTS1373 Permission denied (password,keyboard-interactive).
Ý91.120¨ Connection closed
CoZBatchÝI¨: returning rc=exitcode=255

Note: Some of the path names and hostnames in the data above were changed for security reasons but Co:Z is installed into the right path and password-based authentication from a batch job output to remote servers is functional unless we are using complex passwords with these characters. Any insight into cause would be helpful. Sincerely, -Jadon

[coz]

I suspect that the password was entered into USERID.SOME.DSN.PW.FILE using an emulator running a codepage different from your Unix System Services Codepage. It isn't uncommon for legacy 3270 emulators (in English) to be setup for codepage 037, rather than the now generally standard IBM-1047.

To test this, run the following command from a Unix System Services shell (I've omitted all of the basic characters for this test):

Code: Select all

> echo "<#!^*/\c" | od -h
0000000000    4C  7B  5A  5F  5C  61

Then, browse your password dataset and turn "HEX ON" You should be able to compare the hex values of the special characters from the above test. If, for example you used 037 in your emulator to edit this dataset, you'll see something like this:

Code: Select all

000001 <#!^*/
        475B56
        CBA0C1

Note that all of the characters match except for the caret (^) which is at a different codepoint in the two codepages. If this is the case, it would explain why the password works when entered from the keyboard in PuTTY from USS but not when run as a batch job. To fix this, change your emulator to run under codepage IBM-1047

[Jadon]

Hi Steve,

That was the exact problem sir. Thank you for the solution. We had a code page of "037 United States" set in our 3270 emulation software. When we copied or entered the password into the dataset in ISPF edit with HEX ON and used the caret (^) character it stored it as hex value B0. For Code Page 00037 the hex value of B0 is the caret (^) character but in Code Page 01047 the hex value of B0 is a different character symbol.

We then changed the code page to "1047 United States" in our 3270 emulator software. We entered the password into the dataset in ISPF edit with HEX ON and again used the caret (^) character. It stored this as hex value 5F which is indeed the proper character for Code Page 01047.

Note, the "1047 United States" was for the IBM Personal Communications 3270 client we tested with.

We performed the same test in ERICOM's PowerTERM 3270 client. However, their client (per the User Guide) calls code page 1047 as "Latin-1/Open System".

Along with your guidance, we found the following code page tables very helpful in troubleshooting this:
ftp://ftp.software.ibm.com/software/glo ... P01047.pdf
ftp://ftp.software.ibm.com/software/glo ... P00037.pdf

I hope it's alright to post the links. This may be helpful if anyone else encounters this issue where the 3270 emulation software is not set for the correct code page and causes the password characters placed into the pwdsn= dataset to translate improperly.

Thanks again! Sincerely, -Jadon