openssh unix dev - Jun 2005 - FW: openssh 4.0 - sftp batch mode behavior

Hello,
I just installed the openssh 4.0 for Solaris. The users have reported a
difference in behavior when using the batch mode of sftp client.

Previously they could issue the following command sftp -b batchfile
user at hostname and in the absence of publickey authentication they would
be issued the password prompt and they could enter password and the
process would continue.
After upgrading from 3.1 to 4.0 of ssh, now when the same command is
entered they get the following error message and are not receiving the
password prompt. 
       
       Permission denied (publickey,password,keyboard-interactive).

I have included the output from session in debug mode. Apparently, the
client is not trying any of the other authentication methods.

In the ssh_config file the PasswordAuthentication is set to yes.
       
OpenSSH_4.0p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to hostname [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /home/ssimps/.ssh/id_rsa type -1
debug1: identity file /home/ssimps/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostname' is known and matches the RSA host key.
debug1: Found key in /home/ssimps/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ssimps/.ssh/id_rsa
debug1: Trying private key: /home/ssimps/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
Connection closed

Any assistance would be greatly appreciated.

Thanks,
Searcy Simpson
Acxiom Corporation
501-342-4535
Searcy.Simpson at acxiom.com


**********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.

Simpson Searcy - ssimps wrote:
> Hello,
> I just installed the openssh 4.0 for Solaris. The users have reported a
> difference in behavior when using the batch mode of sftp client.
> 
> Previously they could issue the following command sftp -b batchfile
> user at hostname and in the absence of publickey authentication they would
> be issued the password prompt and they could enter password and the
> process would continue.
The old behaviour was buggy: sftp's -b uses ssh's BatchMode config
option. From ssh_config(5):
> BatchMode
>    If set to ``yes'', passphrase/password querying will be
disabled.
>    This option is useful in scripts and other batch jobs where no
>    user is present to supply the password.  The argument must be
>    ``yes'' or ``no''.  The default is ``no''.
I.e. a sftp client in batch mode shouldn't require any interaction to
function. This stops it from blocking or otherwise misbehaving in
scripts.

If your users need scripted transfers, they can try:

sftp user at host < batchfile

-d