SSHFTPClient.connect: Could not authenticate SSH client

Question

We have a customer using your product and they are unable to connect to us using sftp. We use OpenSSH 3.9p1 and have had good luck with it up until now.

I was wondering if anyone could shed some light on why the SSHFTPClient is failing. Below is an excerpt from our customers log file.

Thanks,
Steve

Class: com.enterprisedt.net.ftp.ssh.SSHFTPClient
Version: 1.5.5
Build timestamp: 8-Nov-2007 09:58:12 EST
Java version: 1.5.0_14
DEBUG [com.enterprisedt.net.j2ssh.transport.publickey.SshPublicKeyFile] 10 Mar 2008 11:44:03.312 : Parsing public key file
DEBUG [com.enterprisedt.net.j2ssh.transport.publickey.SshPublicKeyFile] 10 Mar 2008 11:44:03.328 : Public key is not in the default format, attempting parse with other supported formats
DEBUG [com.enterprisedt.net.j2ssh.transport.publickey.SshPublicKeyFile] 10 Mar 2008 11:44:03.328 : Attempting SECSH-PublicKey-Base64Encoded
DEBUG [com.enterprisedt.net.j2ssh.transport.publickey.SshPublicKeyFile] 10 Mar 2008 11:44:03.328 : Attempting OpenSSH-PublicKey
DEBUG [AbstractKnownHostsKeyVerification] 10 Mar 2008 11:44:03.328 : Allowing interchange-stg.apl.com with fingerprint 1024: 4a 6a 5e 86 5f 52 80 10 35 9e 96 60 bd 3e 8b f5
DEBUG [AbstractKnownHostsKeyVerification] 10 Mar 2008 11:44:03.328 : putAllowedKey(host=interchange-stg.apl.com,algorithm=ssh-rsa)
WARN [AbstractKnownHostsKeyVerification] 10 Mar 2008 11:44:03.328 : Cannot write to known_hosts file as none supplied
INFO [SSHFTPClient] 10 Mar 2008 11:44:03.328 : SSHFTPClient settings validated.
DEBUG [SSHFTPClient] 10 Mar 2008 11:44:03.328 : Connecting to interchange-stg.apl.com:22
DEBUG [TransportProviderFactory] 10 Mar 2008 11:44:03.343 : Connecting to interchange-stg.apl.com:22 via standard socket
DEBUG [SocketTransportProvider] 10 Mar 2008 11:44:03.375 : Invoking connect with timeout=60000
INFO [TransportProtocolCommon] 10 Mar 2008 11:44:03.578 : Timeout=60000
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.578 : Starting transport protocol
INFO [TransportProtocolCommon] 10 Mar 2008 11:44:03.578 : Wait for state update timeout=60000
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.593 : Registering transport protocol messages with inputstream
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.609 : Negotiating protocol version
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.609 : Local identification: SSH-2.0-edtFTPjPRO-1.5.5
INFO [TransportProtocolCommon] 10 Mar 2008 11:44:03.609 : Wait for state update timeout=60000
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.703 : EOL is guessed at LF
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.703 : Remote identification: 'SSH-2.0-OpenSSH_3.9p1' <--- looks like we got connected OK
DEBUG [TransportProtocolCommon] 10 Mar 2008 11:44:03.718 : Protocol negotiation complete


ALL [TransportProtocolCommon] 10 Mar 2008 11:44:04.734 : Received registered message: Name=SSH_MSG_USERAUTH_FAILURE,MessageId=51,PartialSuccess=false,AvailableAuths=publickey,keyboard-interactive
2008/03/10 11:44:04 +0000 [DEBUG] - SVC_OrderMessage_ServiceProvider_APL_FtpUploader: [ConnectivityCheck] Could not establish connection. No connection has been established earlier. Cause: com.enterprisedt.net.ftp.ssh.SSHFTPClient.connect(Unknown Source): Could not authenticate SSH client: FAILED

Answer 1

This could be for a number of reasons - an incorrect password for example if they are using password authentication.

Have they successfully connected before with j/pro or another client such as FileZilla?

Probably best to ask them to email us with a full log file at the ALL level (support at enterprisedt dot com). A small sample app illustrating the problem would be useful also.

If the problem can't be easily diagnosed, if you are able to give us a test account on your server we will try connecting ourselves.

Answer 2

They are using public key authentication (we don't allow password authentication).

Is it possible that our version of OpenSSH is too old?

I'll look into setting up a test account that you could try.

Thanks!

Answer 3

Perhaps try using 'ssh' command line client with '-vvv' and post the debug here, using the same keys.

Answer 4

I think I've confused the situation. We use OpenSSH (as the server) and our customer uses com.enterprisedt.net.ftp.ssh.SSHFTPClient as a client. They don't have a command line ssh capability as far as I know. If I use my OpenSSH command line client from any of our systems to connect to our server it works fine.

The output I posted earlier was effectively their (our customer's) equivalent of -vvv output as far as I could tell.

I trimmed out some of the less important aspects to keep the post smaller but I could post the entire output if you want.

Thanks,
Steve