IBM Ported Tools OpenSSH can loop if you have a SSH_ASKPASS program specified and you also use StrictHostKeyChecking=ask.
What OpenSSH does is to fork/exec your SSH_ASKPASS program to prompt for "yes" or "no". It views the askpass program as a general purpose prompting mechanism. In your case, the SSH_ASKPASS program is a shell script (distributed with Co:Z). In batch, StrictHostKeyChecking should either be yes or no, but I think that we should probably try to find a way to prevent a user from getting into trouble. Maybe the ASK_PASS script should always answer "no" if given this prompt? Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Mar 9, 2015 at 9:04 AM, David Crayford <[email protected]> wrote: > Hey guys, > > We had a bit of situation today when our system crashed due to a problem > with a SMSPDSE address space and a looping Co:Z batch job. We don't know > the root cause > of the problem yet but we suspect it may be a bug with PDSE (there are > PTFs for 2.1). Unfortunately, it had Co:Z fingerprints that I had to > explain to my management. > > *The symptoms:* > > One of our testers ran a job on Friday where they had edited a Co:Z batch > job to turn on trace and had replaced the > ssh-options=-oStrictHostKeyChecking=no > option with ssh-options=-vvv to put a trace on. The tester knows very > little about Co:Z or ssh and had not setup any key files so it's a > reasonable mistake to make. > The batch job was using a password file, the complete command deck is as > follows: > > //COZCONF DD DISP=SHR,DSN=SYS3.COZ.SAMPJCL(COZCFGD) > // DD * > ssh-options=-vvv > server-env-PASSWD_DSN=//FUW130.DEVT.INSTALL(VAGPASS) > server-env-SSH_ASKPASS=/usr/local/coz/bin/read_passwd_dsn.sh > server-env-DISPLAY=none > /* > > The job output: > > /usr/local/coz/bin/read_passwd_dsn.sh prompt: "Please type 'yes' or 'no': > " > fromdsn(FUW130.DEVT.INSTALL(VAGPASS))[N]: 1 records/200 bytes read; 8 > bytes written in 0 milliseconds. > debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. > (errno2=0x056201A9) > > > The ssh_config specified "StrictHostKeyChecking ask" so the job went into > a loop continuously spawning OMVS processes. It ran for three days creating > quite a lot of trace data > on the spool which is not a big problem but this morning we started to > experience abends starting with a S04F and then lots of S0D6 abends in the > spawned Co:Z process. I have looked > at the dumps and it looks like PDSE became unstable and couldn't be > accessed via a PC call. Because the Co:Z launcher was looping and each > spawned task was abending with a dump > our system became unstable as the dump address space couldn't keep up and > overspilled storage into ESQA eventually bringing our system down. We had > IPL to resolve the problem. > > We have sent the original dump to IBM as we suspect the problem is we PDSE > but my question can we tweak the Co:Z launcher so it doesn't loop when the > options are specified > as above. > > Is it possible to just bail on the first password error? > > Regards, > David > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
