Use of passwords when at OpenSSH_5

[aramsey]

Hello. We are implementing OpenSSH_5. When I use password authentication I get the following messages:

debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. (errno2=0x056201A9)
debug1: permanently_drop_suid: 0
fromdsn(TCPIP.USER.SFTPPASS(ANNSFTP))[N]: 1 records/80 bytes read; 9 bytes written in 0.015 seconds (600.000 Bytes/sec).
debug3: packet_send2: adding 64 (len 60 padlen 4 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).

In some of my testing I have actually gone into a loop with the can't open and permanently_drop messages, but usually it works as above.

I opened a ticket with IBM and they stated I have to ensure that I have the oBatchmode=no parameter first. I specify it first in my $SSH_OPTS, but cozsftp places 3 other parameters prior to it -

debug3: connect_to_server arg=/bin/ssh
debug3: connect_to_server arg=-oForwardX11 no
debug3: connect_to_server arg=-oForwardAgent no
debug3: connect_to_server arg=-oClearAllForwardings yes
debug3: connect_to_server arg=-oBatchMode=no

I am at an earlier Co:Z release (1.50), but I found an entry in this forum that showed release 1.70 and the arguments were still in this order. Is there an intended fix for this?

Thank you,
Ann

[coz]

In the trace that you provided, all looks fine.

Can you post a trace of the failing case?
Note that if the password is rejected by the server, that the client will normally retry 3 times. Is this the loop that you are referring to?

We don't think that the order of the -o arguments are the problem. However, as per our JCL example, the -oBatchMode argument must precede the "-b" switch.

[aramsey]

Hi Steve,

My concern is the two DEBUG1 messages that are in the trace I supplied -

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

I had never received them prior to going to OpenSSH_5. You state that the trace looks fine, so does that mean that you consider the above messages normal? I know that in this case it moved on and the password was accepted, but since I have had it not make it past those messages on a couple of occassions, I am concerned with these messages. I would prefer not to see them at all if I am at risk of the SFTP not working on occassion due to them.

If what you mean by a copy of a failing trace is you want to see what it looks like when it is in a loop, that would be -
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. (errno2=0x056201A9)
debug1: permanently_drop_suid: 0
debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. (errno2=0x056201A9)
debug1: permanently_drop_suid: 0
debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. (errno2=0x056201A9)
debug1: permanently_drop_suid: 0

etc until I cancel the job. The issue here isn't the fact that the password is being rejected by the server.

I am going to provide you with a copy of my STDIN so you can see how I have placed the -oBatchMde=no in my job:

. /etc/sshagent/agent-info
export PASSWD_DSN='//TCPIP.USER.SFTPPASS(ANNSFTP)'
export SSH_ASKPASS=/sftp/coz/bin/read_passwd_dsn.sh
export DISPLAY=none
ssh_opts="-oBatchMode=no
-oPreferredAuthentications=password,publickey"
/sftp/coz/bin/cozsftp $ssh_opts -vvv -b- yesmara@10.20.23.34
lzopts mode=text,linerule=lf
lzopts -a
pwd
ls -l
-put //DD:UPLOAD testfile_textlf.txt
ls -l


Thank you,
Ann

[aramsey]

I forgot to ask you - do you see those two messages when you use password authentication for your client and OpenSSH_5? If not, there is probably something wrong with my config..

Thank you,
Ann

[coz]

Ann,

The following messages from IBM Ported Tools OpenSSH are debug messages, and are not errors (and are expected in this context):

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device. (errno2=0x056201A9)
(Means that the code is testing to see if you are connected to a terminal, which you are not).

debug1: permanently_drop_suid: 0
(Is a debug message that has to do with changing from super-user to regular user mode before running the SSH_ASKPASS program).

So, these messages don't concern us, and we see them when we run the cozsftp client with IBM OpenSSH 1.2 (5.0p1).

The problem seems to be the loop...

We have some questions:

- Can you email us the entire trace to info@dovetail.com? We need to see the rest of the debug messages.

- Why are you setting the -oPreferredAuthentications option?
What are you setting in ./etc/sshagent/agent-info?
Where is the "<<EOB" here-document delimiter on the end of your cozsftp command line? What you have sent us in this script will not work.

- The authentication is done by the IBM ssh code. Can you rerun this with the IBM sftp client (removing cozsftp from the scenario) to verify that you have the same problem? You will have to change your script to something like:

export PASSWD_DSN='//TCPIP.USER.SFTPPASS(ANNSFTP)'
export SSH_ASKPASS=/sftp/coz/bin/read_passwd_dsn.sh
export DISPLAY=none
ssh_opts="-oBatchMode=no"
# Use IBM's sftp client with "here-document" input:
sftp $ssh_opts -vvv -b- yesmara@10.20.23.34 <<EOB
ls -l
EOB

Please try this and if it doesn't work, email us the trace output.

Hope this helps.

[aramsey]

I have just emailed you the job log when I get the loop - as I stated in the email, in my previous updates I left out one of the messages that is included in message loop - the fromddsn message.

In answer to your questions -
I have the-oPreferredAuthentications option set because one of the servers that we were going to would deny our access after going through our public keys, prior to our getting to the password authentication. This allowed us to send the password first.
The ./etc/sshagent/agent-info is so the client will connect to the sshagent and get the passphrase for the private key - not needed here.
The loop will occur even if neither of the above are specified - which is the case in the job output that I just sent you.

Good eyes in seeing that I was missing the EOB delimiters. I have it in all of my input members that the analysts use, I just forgot them in this jobstream. Thing is, it actually did work without them. The job that I have included in my email does have them in though.

I have yet to get the w/o cozsftp to work. I run it, get 0 condition codes, but have absolutely no output. I tried putting all of the output into files on my home directory but they are still empty. I am going to try setting the job up more like I did my SFTP batch jobs that I had before I used COZSFTP and see if I can see any results. I will let you know what the results are then.

Thank you,
Ann

[dovetail]

We looked at your trace, and the problem that we see is a loop in the authentication (using a passwod). Does this loop happen each time or only under certain circumstances?

We can see that the SSH_ASKPASS program is being called by IBM Ported Tools ssh and that it is returning a password, so the problem doesn't seem to be there.

Since authentication is handled by ssh (IBM Ported Tools), we would ask you to reproduce this problem using IBM Ported Tools sftp and to report the problem to IBM.

Adapting your script, something like the following should work to allow you to use IBM sftp rather than Co:Z sftp:

# first, copy the dataset to an HFS file (if necessary)
/sftp/coz/bin/fromdsn //DD:UPLOAD /tmp/test.upload.txt

export PASSWD_DSN='//TCPIP.USER.SFTPPASS(ANNSFTP)'
export SSH_ASKPASS=/sftp/coz/bin/read_passwd_dsn.sh
export DISPLAY=none
ssh_opts="-oBatchMode=no"
sftp $ssh_opts -vvv -b- foo@bar <<EOB
ascii
pwd
ls -l
-put //tmp/test.upload.txt testfile_textlf.txt
ls -l
EOB

[aramsey]

Hello again! This seems to happen all the time on the LPAR that I am currently testing on. It happened to me twice on another LPAR and hasn't since - I have not been able to recreate it there. I do not believe I changed anything at all between the looping situation and the non-looping situation on that LPAR, but now I am not 100% sure.

I am unable to get the SFTP that you provided to work - I am getting -

CoZBatch: executing default progname="-/bin/sh"
CoZBatch[D]: spawning progname=/bin/sh
CoZBatch[D]: argv[0] = -/bin/sh
CoZBatch[D]: current environment:
CoZBatch[D]: >TZ=CST6CDT<
CoZBatch[D]: >LIBPATH=/lib:/usr/lib:.<
CoZBatch[D]: >_EDC_ADD_ERRNO2=1<
CoZBatch[D]: >HOME=/DV1/u/cdp0021<
CoZBatch[D]: >_BPX_SHAREAS=MUST<
CoZBatch[D]: >_BPX_SPAWN_SCRIPT=YES<
CoZBatch[D]: >_BPXK_JOBLOG=STDERR<
CoZBatch[D]: >PATH=/bin:/usr/bin<
CoZBatch[D]: spawned /bin/sh (50462918)
CoZBatch: returning rc=exitcode=126
sftp: FSUM9209 cannot execute: reason code = 0b1b0473: EDC5157I An internal error has occurred.

I am still looking into that, but if you could provide any insight, that would be great!

Thank you,
Ann

[aramsey]

Never mind - I removed my BPX_SHAREAS=MUST from my environmental variable and I now get to the point where I also loop with this code. I will go ahead and pass this on to IBM.

Thank you very much -
Ann

[aramsey]

Well you are going to think I am completely off, but now I am again (still?) getting the error that I stated in my update earlier when I do the SFTP without cozsftp. Since I don't have any job to look at from when I think it worked, now I am now not sure if I submitted my SFTP job or my cozsftp. But when I run now, I still have the same environmental variables that were included above - I am trying to figure out where COZBATCH gets its environmental variables from. I am not sure if they are the reason the SFTP job is not running, but thought that I could at least play with them.

Thanks again - Ann

[aramsey]

Just an explanation for all my previous rantings - the job with the SFTP sometimes goes into the loop, sometimes it gets the :

CoZBatch: returning rc=exitcode=126
sftp: FSUM9209 cannot execute: reason code = 0b1b0473: EDC5157I An internal error has occurred.

I ran it many times and determined it just wasn't consistent, it didn't matter if I changed anything or not. So I apologize for the back and forths. I have opened a ticket with IBM and I will see what they say.

Thanks again - Ann

[dovetail]

So, are you able to reproduce the problem (password authentication loop using SSH_ASKPASS) using IBM Ported Tools sftp client?

[aramsey]

Yes - I replaced the
/sftp/coz/bin/cozsftp $ssh_opts -vvv -b- yesmara@10.20.23.34 <<EOB
statement with
sftp $ssh_opts -vvv -b- yesmara@10.20.23.34 <<EOB
and was able to recreate the loop.

[aramsey]

I thought I would let you know that I believe that I found the cause of the loop. The last message prior to the looping messages was:
debug2: no key of type 2 for host 10.20.23.34

There was no
FOTS1370 Host key verification failed.

It appears the OpenSSH code falls through this when using password authentication and there is no host key in known_hosts. I have fixed my problem by adding the host_key to the known_hosts file and I have passed this information on to IBM. I just thought I would let you know after having you look into it for me. I should have done that compare a long time ago!

Thanks!