public key authentication using wodSFTP 2.2.2 (eva (wodSFTP / wodSFTP.NET / wodSFTPdll)
I am using wodSFTP 2.2.2 (eval) in a PowerBuilder 8.0.4 development environment.
My SFTP server is Bitvise WinSSHD 3.31 (eval). It is configured to authenticate via either a password or a public key.
I can use wodKeys to generate, import, and export keys. Everything seems to work fine: imported and exported keys are compatible with other applications, and MD5 fingerprints match after transferring keys.
I can use wodSFTP to connect to the SFTP server, using code similar to this:
wodSFTPObject.Authentication = authPassword {value=1}
wodSFTPObject.Password = as_PassWd
(where as_PassWd is a string variable that contains the printable text for the password)
It connects fine.
ISSUE #1
Right after a good connection with password, I disconnect, and change parameters to public key, like this:
wodSFTPObject.Authentication = authPubkey {value=2}
wodSFTPObject.PrivateKey = abl_MyKey
(where abl_MyKey is a blob variable that contains the binary string of the private key)
I then attempt to connect again.
I get a successful connection, but wodSFTP is using the old password (instead of the requested public key). This doesn't sound right.
I can get rid of this behavior by explicitly clearing the password like this:
wodSFTPObject.Password =
wodSFTPObject.Authentication = authPubkey {value=2}
wodSFTPObject.PrivateKey = abl_MyKey
ISSUE #2
Now I am set up for authentication only via public key:
wodSFTPObject.Password =
wodSFTPObject.Authentication = authPubkey {value=2}
wodSFTPObject.PrivateKey = abl_MyKey
But I can't connect. I get:
error number = 30015
error text = Invalid username or password reported by server.
I am reasonably sure that I have everything configured properly: After setting the wodSFTPObject.PrivateKey property, I can read it back and get the same key. I can use a different SFTP client (Secure FX 2.2.9) to connect to the SFTP server using public key authentication.
Do you have any suggestions?
Re: public key authentication using wodSFTP 2.2.2
Hmm. Not sure why in ISSUE1 wodSFTP sends old password, it shouldn't. I cannot double-check this until tuesday, but I will try it out at that time.
As for ISSUE2 - it looks ok. Only thing that comes to my mind is question - what exactly do yuo put in PrivateKey property? Is it wodKeys object, or something else?
Re: public key authentication using wodSFTP 2.2.2
Not sure why in ISSUE1 wodSFTP sends old password, it shouldn't.
I cannot double-check this until tuesday, but I will try it out
at that time.
Excellent! I look forward to your results!
what exactly do you put in PrivateKey property? Is it wodKeys
object, or something else?
I assign to the PrivateKey property a variable of type blob . In PowerBuilder, regular character strings are null-terminated (like in C), so they can not contain arbitrary binary data. The blob type is like a string, but can contain anything.
The raw binary key that I assign to the PrivateKey property was previously extracted from a wodKey object.
When I assign the binary key to PrivateKey, no exception is thrown. Then I can read back the PrivateKey property, and get the same data. So, I assume that the key is acceptable to wodSFTP.
It might be nice if wodSFTP had BubbleBabble and FingerPrint properties, just as wodKey does. This would allow me to confirm that the correct key is loaded.
Re: public key authentication using wodSFTP 2.2.2
Dennis,
but what is in your blob? Reference to wodKeys or something else?
Re: public key authentication using wodSFTP 2.2.2
but what is in your blob? Reference to wodKeys or something else
The blob contains the raw binary data for the key itself. In this case, it is a 1024-bit private DSA key.
It is not a LPDISPATCH from the IKeys object. It isn't an object at all, just data for the key.
Re: public key authentication using wodSFTP 2.2.2
Dennis,
any chance you can zip PB executable that connects to your server using your key, and send it to me? I'd like to try it out, and debug under the hood to see what could possibly be the reason this all happens.