SFTP error code 103

[Phil.Barila]

I found a thread on this forum (http://www.scootersoftware.com/vbull...2526-Error-103) that is the same symptoms as I'm getting.

Version 4.0.3 (build 19420), installed yesterday.

[COLOR=#0000ff]1/9/2015 2:32:48 PM  Connecting to host.domain.com
[/COLOR]1/9/2015 2:32:48 PM  Server key [ssh-rsa 2040 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx]
[COLOR=#0000ff]1/9/2015 2:32:48 PM  Authorization successful.
1/9/2015 2:32:48 PM  Connection failed: Failed to establish SFTP connection (error code is 103)
[/COLOR]1/9/2015 2:32:48 PM  Connection closed.
[COLOR=#ff0000]1/9/2015 2:32:48 PM  Unable to load sftp://[email protected]/directory: Failed to establish SFTP connection (error code is 103)
[/COLOR]

This connection used to work. It broke when we upgraded the openssl and sshd on our AIX box, which required a key regeneration. WinSCP has no trouble connecting to this box with the new key. Cygwin SSH and PuTTY also connect without any issues. Only BC4 has a problem. I'm using a saved PW. When I don't use the saved PW, and remove the cached key from BCProfiles.xml, I get the following:

[COLOR=#0000ff]1/9/2015 2:32:48 PM  Connecting to host.domain.com
[/COLOR]1/9/2015 2:32:48 PM  Server key [ssh-rsa 2040 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx]
[COLOR=#ff0000]1/9/2015 2:48:37 PM  Public key agent authorization failed.
1/9/2015 2:48:37 PM  Keyboard interactive authorization failed.
[/COLOR]

(Enter PW here)

1/9/2015 2:48:52 PM  Connection closed.
[COLOR=#ff0000]1/9/2015 2:48:52 PM  Connection failed: Connection lost (error code is 10058)
[/COLOR]

I can probably do some more forensic examination if you tell me what you want to see.

Thanks.

[Chris]

Phil,

I replied to the email you also sent. You can reply here in the forum or by email, whichever is most convenient.

Copy of what I sent by email:

We just determined today that we have a bug (#0005317) that makes SFTP connections with private keys fail, it appears specific to newer versions of openssl.

In my testing, CentOS 5.11 with OpenSSL 4.3 worked with a private key, but CentOS 6.6 with OpenSSL 5.3 failed. We also had a customer report a failure with CentOS 7.

What version of OpenSSH is on your AIX box? To display the version, run "ssh -V".

[Phil.Barila]

user@host ~
$ ssh -V
OpenSSH_6.0p1

user@host ~
$

Anything else I can do?

[Aaron]

Hello,

I'm afraid this may be related to a bug we found here:
http://www.scootersoftware.com/vbull...n-EC2-and-mac)

We're still narrowing down exactly which versions of OpenSSH are affected, and we're working on a fix (not in 4.0.4, just released).

[Phil.Barila]

I would guess it's related. I look forward to you sorting it out quickly and getting out a fix.

Please ask if there's any additional forensics you'd like me to perform.

Phil

[Chris]

Phil,

We just released Beyond Compare 4.0.5 with updated SSL support. Please let us know if it resolves your issue.

To update, open "Help > Check for Updates" in BC or run the installer from our website and select "Upgrade" as the install type.

[Phil.Barila]

I'm so very sorry to tell you that Version 4.0.5 (build 19480) fails with the same symptoms.

[Aaron]

Hello,

Could you try regenerating a new key? Sometimes, we have seen issues with a specific key pair that causes odd problems. We also have a KB article to help generate and setup a key:
http://www.scootersoftware.com/suppo...ftp_privatekey

If you are following different steps, how do any deviate from the above guide?

Also, we do still have a bug where a copy of the .pub file is needed on the client (bc4) machine in the same directory as the private key if you have a passphrase. This is a known issue we are still looking into; in the meantime, I suggest having the matching .pub alongside your private key.

[Phil.Barila]

We're using username/PW authentication. The only private key is on the server. The server's public key is cached, of course. Are you testing against this scenario?

As noted above, Cygwin SSH, PuTTY, and WinSCP all connect with this server, using its key pair, just fine.

[Aaron]

Hello,

Given that your setup works in other applications, it is likely we should be able to use it, too, and that we have a few kinks to still work out. 4.0.5 implemented a new major version of a helper library, and we tested against a variety of servers for increased support, but still have a few holes to fix.

For general terminology, the expected setup is to use either a Username/Password or a Key Pair for connection. If both are defined, we use one first and if it fails fall back on the other. A Key Pair can be defined with a Passphrase, which prompts for a password but isn't the same authentication. So I would expect that you are using either Username/Password or a Key Pair (with an optional Passphrase).

The guide I link to above has the steup instructions for the Key Pair. The Public (.pub) key is the key that is on the server, as other users could potentially access that system and find that key. It's added to the authorized_keys file. The private key is kept private on your client machine. When you connect, the client checks the public key on the server vs. the private key locally and tries to authenticate.

For troubleshooting purposes, I'd recommend defining the BC FTP Profile to use either Username/Password *or* the Private key. This way, we can troubleshoot a specific connection method.

If you generate a new key pair using the above article's steps, does this help? As I mentioned, we've seen an odd issue a couple times where BC has trouble with specific key pair files and regenerating the key can sometimes help.

[Aaron]

Hello Phil,

Also, would it be possible to get a sample/test account that we could try connecting against? That would greatly help our troubleshooting.

[Phil.Barila]

Aaron,

We are currently only using username/PW, the only key pair involved is the server's, wherein it offers the public key when making the initial connection, and BC caches it, just like all the other clients.

I'm afraid that a test account on that system is not possible under current circumstances.

If you give me a debugging client with obnoxious levels of logging, I'll be happy to test that for you and send back the logs.

.
.
.

I've just determined that we need to rev the OpenSSL libs on the AIX box in question, so I'll retest the current version (unless you give me something new to test in the interim) when we get that done.

Thanks,

Phil

[Aaron]

Hello,

Ah ha, thanks for that clarification. The server's Host Key is a different concept, and is unrelated to the ssh public/private key pairs used for connection and defined as part of the profile. The Host Key dialog pops-up on first connection, and can be remembered. If this is what you have been referring to, please be sure that in your FTP Profile settings that the SSH Private Key path and SSL client certificate are blank.

[Phil.Barila]

Aaron,

I get all that. I haven't used key pairs yet, though we will eventually go there.

At present, the box is using 1.0.1e, which will be replaced Real Soon Now. I'm not sure the delta between 1.0.1e and current matters to the connection issue we're seeing, but it might.

However, the fact remains that BC is the only tool I use that can't SFTP or FTPS to this box, using only a username/PW.

Phil

[Aaron]

Thanks. We also have a few more fixes incoming for the next minor (4.0.6) release that might help as well. Would it be possible to get a test account? You can email us with details at [email protected] and please include a link back to this forum thread for our reference.