Batch job loops when reading pwdsn file

[EvanC]

Hi,

When reading the pwdsn file, a batch job loops and must be canceled. Here's a sample of the messages that are written before the job is canceled:

CoZBatchÝN¨: Copyright (C) 2005-2009 Dovetailed Technologies LLC. All rights reserved.
CoZBatchÝN¨: version 2.0.1 2012-01-14
CoZBatchÝI¨: executing progname=login-shell="-/bin/sh"
Connect using SSH_ASKPASS, password will be read from TS00006.COZ(MYPW)...
Executing: /TECH/u/coz/bin/cozsftp -oBatchMode=no -oConnectTimeout=60 -oServerAliveInterval=60 -oPubkeyAuthentication=n
o -b- xxxx@xxxx
Co:Z SFTP version: 2.0.1 (5.0p1) 2012-01-14
Copyright (C) Dovetailed Technologies, LLC. 2011. All rights reserved.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0 milliseconds.
fromdsn(TS00006.COZ(MYPW))ÝN¨: 1 records/80 bytes read; 9 bytes written in 0.001 seconds (8.789 KBytes/sec).

I would appreciate any help in resolving this problem.

Thanks,

Evan

[dovetail]

Have you tested connecting to this server interactively with sftp using the same password? It appears that you are sending an 8-character password, is this correct?

It looks like the server is rejecting the password, but normally it should only retry based on the "NumberOfPasswordPrompts" setting in IBM Ported Tools OpenSSH. The default for this is 3, but perhaps you have changed this in your system configuration? (/etc/ssh/ssh_config or $HOME/.ssh/ssh_config)

Try adding these lines to your script:

Code: Select all

sftp_opts="$sftp_opts -oNumberOfPasswordPrompts=1"
sftp_opts="$sftp_opts -vvv"

This will generate a some trace output from IBM Ported Tools OpenSSH, please post this or email to info@dovetail.com and we'll take a look.

[dovetail]

Evan,

Looking at your log, the problem is this:

debug2: no key of type 0 for host tst0
..
debug2: no key of type 2 for host tst0

which means that you don't have an entry for this host in your known_hosts file.
There is apparently a bug in IBM Ported Tools OpenSSH that causes this to loop and keep prompting for a password.

There are a couple of possible workarounds:

1) add the ssh option "-oStrictHostKeyChecking=no"
This will automatically accept a host key for a new host connection (but will still fail if the remote host's key doesn't match an existing entry in known_hosts).

2) connect from an interactive session and manually accept the host key.

[dovetail]

The loop in IBM Ported Tools OpenSSH calling the SSH ASKPASS program is because the program is called to prompt the "user" to accept the host key! Of course, this is not what you want in a batch job. This is happening because the default for the SSH option "StrictHostKeyChecking" defaults to "ask".

So, the best workaround for this is to set:

Code: Select all

sftp_opts="$sftp_opts -oStrictHostKeyChecking=yes"

or

Code: Select all

sftp_opts="$sftp_opts -oStrictHostKeyChecking=no"

Note: "no" means that the server's host key will be automatically accepted for a new host. "yes" means that the connection will fail if the host's key is not known. Connections will *always* fail if the host's key doesn't match the key that the client already knows.

If you are using the new sample JCL/PROC/scripts that we starting shipping in 1.10.1, then you can add one of these two lines above to your "SFTPIND" (installation defaults) member to avoid this problem. We will update this in the upcoming 2.1.1 release to set -oStrictHostKeyChecking=yes.