Logging on with password

[jack.weatherford]

We are attempting to logon to a remote server from a ZOS 1.13 mainframe using PASSWORDs for an initial cut at using SFTP/SSH.
When the connection is first made the server presents us with a series of messages and expects to receive an 'OK' response before prompting for the password.
How do we first respond to this and then to the password prompt.

[coz]

Tell me a little more about your setup.

Are you trying to run the cozsftp client from a batch job?

If so, are you using our sftp_batch sample scripts located in COZ_HOME/samples/sftp_batch?

Have you specified the pwdsn option in your sample job?

In general, sftp server products don't prompt for anything prior to authentication - what kind of remote system are you connecting to, and what sftp server software is it running?

[jack.weatherford]

we are using the samples as a basis.
this is the job as run
//RUNCOZ EXEC PROC=COZPROC,ARGS='jmadigan@asftptest.cadm.harvard.edu'
//COZCFG DD *
ssh-options=-oStrictHostKeyChecking=no
server-env-PASSWD_DSN=//SISNT.STAGE.JCL(PSWASFTP)
server-env-SSH_ASKPASS=/ifox/coz/bin/read_passwd_dsn.sh
server-env-DISPLAY=none
//STDIN DD *
uname -a
env

the COZLOG shows this.
********************* W A R N I N G *********************

This system is for authorized users at XXXXXXXXXXXXXXXXXX
No other use is permitted.

***** Server Operations Center *******
********************* (XXX) XXX-XXXX *********************
FOTS1346 Permission denied, please try again.

FOTS1346 Permission denied, please try again.

FOTS1373 Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

using another post as an example I have also done a :

export PASSWD_DSN='//XXXXXXXXXXXXXXXXXXXXXXXX'
/ifox/coz/askpassxxxxxxxxxx
and it has returned the password so I know that part is working.

according to the user when they manually connect they have to respond OK to the warning messages prior to supplying the userid and password.

I can not answer the type of system nor the server software.

[dovetail]

You are using JCL for running the Co:Z Launcher, not Co:Z SFTP.
See the "SFTPSAMP" sample JCL for running SFTP.

But this doesn't explain why your password isn't being accepted.
If you want to debug this with Co:Z Launcher, you can add this to the ARGS:

Code: Select all

//RUNCOZ EXEC PROC=COZPROC,ARGS='-LT,t jmadigan@asftptest.cadm.harvard.edu' 

and this option:

Code: Select all

//COZSFG DD *
ssh-options=-vvv

This will collect some tracing data. Please download the entire job output to a file and send to us at info@dovetail.com and we will take a look.

Note: you can use the "fromdsn" z/OS UNIX shell command to grab all of the output for a job:

Code: Select all

fromdsn -S -JES.J1234.all > j1234.job.txt

[jack.weatherford]

Based on your responses I moved to a sandbox set of systems and begin fresh using CO:Z on one system and native SSHD on the other, both are mainframe systems running zos 1.13. I also started from scratch with the SFTPSAMP. I have been able to successfully logon and transfer files this way, after what seems like a hundred attempts.

The only issue I have now is that after each successful run the target SSHD task terminates with no messages. as soon as the connection is closed it shuts down.
in the log i see connection closed by (the sending system).

[dovetail]

If IBM Ported Tools SSHD is shutting down after each request, then it probably isn't set up correctly.

Please refer to: http://www-03.ibm.com/systems/resources/fotza501.pdf
Chapter 5, "Ways to start sshd as a stand-alone daemon".
I would suggest that you start it as described under "Using BPXBATCH" (an SSHD started task / cataloged procedure).

[jack.weatherford]

I seemed to have remembered a similar issue in a previous post.
Sure enough the solution was there ..... remove the -ddd from the startup. Debugging shuts the process down after one use. removed and all is fine

Thanks

[dovetail]

that would do it.

If you want debugging of a production SSHD, then look at setting "LogLevel" in sshd_config.
It is even possible to set this with "Match" for certain userids.

[jack.weatherford]

Having fixed a couple of the problems pointed out to me in my previous post... like using the wrong PROC/process I am now working on the origonal system and I am once again getting permission denied after connecting to the host.
These are the messages I am getting:
fromdsn(SISNT.STAGE.JCL(PSWASFTT))ÝN¨: 1 records/80 bytes read; 9 bytes written
debug3: packet_send2: adding 32 (len 88 padlen 8 extra_pad 64)

debug2: we sent a password packet, wait for reply

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi

debug3: __catgets: NLS setup complete (1), using message catalog openssh.cat

FOTS1346 Permission denied, please try again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. (errno2=0

debug1: permanently_drop_suid: 0

fromdsn(SISNT.STAGE.JCL(PSWASFTT))ÝN¨: 1 records/80 bytes read; 9 bytes written
debug3: packet_send2: adding 32 (len 88 padlen 8 extra_pad 64)

[dovetail]

I would suggest that you verify that you can log in interactively from one LPAR to another.

To do this, first log in to the first LPAR using ssh (like PuTTY), into a z/OS Unix shell.

then, from the ssh shell on the first, try to log in to the second:

zos1> ssh -vvv myid@zos2

verify that you can connect and that the password is accepted interactively.

This procedure is only using ssh (from IBM Ported Tools).

[t01bj64]

I experienced a similar issue using Co:Z 2.4.0, I tested and was manually able to log onto server successfully.

To correct the issue, what I've found was my password dataset was passing line characters in cols 72-80.
1.) Turned NUM OFF
2.) Delete line characters between cols 72-80

Job reran successfully.

Note: This problem only occurred when host server was Windows. Unix, Linux, etc all worked fine regardless.

************************************************************************************************
debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

debug3: __catgets: NLS setup complete (1), using message catalog openssh.cat

FOTS1373 Permission denied (publickey,gssapi-with-mic,password).

Ý09.689¨ Connection closed
CoZBatchÝI¨: returning rc=exitcode=255
*************************************************************************************************