SFTP Public Key Authentication With Passphrase No Password

[paamac]

Using SFFS on a Windows server we are setting up a new SFTP replication to an internet host that will use RSA public key authentication. The key pair was generated with a passphrase (a requirement for us), but the associated account on the SFTP server has no login password. When we try to run a synchronization profile with the username saved and password blank, SFFS shows an SSH 114 error and prompts for a username and password. We supply the username and no password but then SFFS will always show a dialog telling us that "Cannot access sftp://w.x.y.z/path (User name or password is missing)". But as mentioned, there is no password for the account.

We can take the private key involved (OpenSSH format) and convert it to PuTTY format for use with WinSCP and verify that we can log on to the SFTP host using the private key, same username, and no password. So the key pair and passphrase being used are confirmed correct.

How can we fix this?

[superflexible]

Here are the instructions.

1. FTP DIALOG, FIRST TAB SHEET
------------------------------
Enter User ID but no password.
Save User ID (checked)

2. CERTIFICATES TAB SHEET
-------------------------
Name: My Certificate (for example)
Certificate/Private Key File: C:\Users\Tobias\.ssh\id_rsa
Public Key File: C:\Users\Tobias\.ssh\id_rsa.pub
***** NOW CLICK ADD BUTTON!!!! *****

3. SECURITY TAB SHEET
------------------
Choose the certificate from the drop-down menu in the lower right
half of the dialog. Specify the password for the file.
Remove "User Name / Password"

[paamac]

Hello,

We have used these settings and again used them from scratch but still are seeing SSH error 114 and are being prompted for a password. I am including an attachments of screenshots. Note that the checkbox for "Save password" always reverts back to being checked after unchecking it and clicking "OK".

How can we get this to work? Why is it prompting for a password when none is necessary? As the *'s indicate, we have entered the passphrase for the RSA key pair ("certificate"). It is the correct passphrase, directly pasted the same way we verify it for use via WinSCP (which uses a PuTTY-formatted version of the key instead of OpenSSH).

[superflexible]

I would need to see the log file. You will find messages about whether the certificate could be loaded in the log file.

Syncovery uses PuTTY format too, so maybe it's just the wrong format.

[paamac]

I am attaching a sanitized version of the log file for your review. I note that custom SSH port 8022 does not show up in the log, so presumably the job run failed at the local certificate check, however why the username and password prompt then?

[superflexible]

As you can see in the log, there is an error loading the private key from your file .id_rsa

The error code 3337 means that the Certificate Password is wrong. The password is given on the Security tab sheet of the Internet/FTP dialog and it can be max 24 characters long, as the label in the dialog explains. Maybe yours is too long?

Because certificate authentication fails, the program falls back to asking for a password.

[paamac]

The passphrase used with the key pair is 25 characters long, so that looks like the likely source of the problem. We will generate a new key pair with a shorter passphrase. Hopefully that will resolve our issue.

Thank you