setAuthentication() public key authentication

Question

Hi,

I am wondering if you have an example of the setAuthentication(keyfile, username, keyfile_password) in which the password is null, or when the public/private key was created, enter was pressed signifying no password. I have spent a fair amount of time trying to code the ftp client to be able to do public/private key authentication with not passing through the actual ftp server password. I have looked through all of your examples and have not yet gotten something to work. Right now, I am on version edtftpj-pro-1.2.3 but will be upgrading to the newest version soon. I am also using class SSHFTPClient with Java 1.4.2.03 Thanks.

John

Answer 1

Version 1.2.5 has better examples, you can see a simple key authentication one here:

http://www.enterprisedt.com/products/ed ... eadme.html

Try passing in an empty string for the password (not sure if that will work but try). If you are still having problems we'll try it out.

Hi,

I am wondering if you have an example of the setAuthentication(keyfile, username, keyfile_password) in which the password is null, or when the public/private key was created, enter was pressed signifying no password. I have spent a fair amount of time trying to code the ftp client to be able to do public/private key authentication with not passing through the actual ftp server password. I have looked through all of your examples and have not yet gotten something to work. Right now, I am on version edtftpj-pro-1.2.3 but will be upgrading to the newest version soon. I am also using class SSHFTPClient with Java 1.4.2.03 Thanks.

John

Answer 2

I have recently recieved this failure after getting the public key authenication working based off the SSH API. Any ideas as to what could be causing this?



Failure:
com.enterprisedt.net.j2ssh.sftp.SftpSubsystemClient.getOKRequestStatus(SftpSubsystemClient.java:923)
com.enterprisedt.net.j2ssh.sftp.SftpSubsystemClient.renameFile(SftpSubsystemClient.java:634)
com.enterprisedt.net.j2ssh.SftpClient.rename(SftpClient.java:981)
com.enterprisedt.net.ftp.ssh.SSHFTPClient.rename(Unknown Source)
com.alliantenergy.datatransfermanager.inputadapter.SFTPReadInputAdapter.renameFileTo(SFTPReadInputAdapter.java:237)
com.alliantenergy.datatransfermanager.inputadapter.SFTPReadInputAdapter.completeClean(SFTPReadInputAdapter.java:162)
com.alliantenergy.datatransfermanager.job.EAIJob.cleanupInputAdapter(EAIJob.java:226)
com.alliantenergy.datatransfermanager.job.EAIJob.execute(EAIJob.java:142)
org.quartz.core.JobRunShell.run(JobRunShell.java:195)
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

Answer 3

Would you be able to provide us with the name and message of the exception being thrown please?

- Hans (EDT)

Answer 4

That is the actual error message that I had recieved from the API. I think that I was either trying to rename the file to the same name or to a null value in which the API was complaining. Once I stopped renaming the file to that value, everything worked ok.

Would you be able to provide us with the name and message of the exception being thrown please?

- Hans (EDT)

John

Answer 5

I'm sorry to labour on this, but when you say you received it from the API, what exactly do you mean? Did you catch an exception or did you copy and paste the stacktrace out of a log file?

The method in which the error originates throws 4 different exceptions so knowing the exception type and message would be really helpful. Two of them relate to standard error messages received from the server (e.g. "no such file" or "permission denied"), and the other two relate to probable failures in the SSH comms. Unfortunately the line-number doesn't help me to differentiate - probably because the source code has changed since your version.

Incidentally, if you did pass in the same name or a null, then it wouldn't be surprising to me if the server did complain about that.

- Hans (EDT)

Answer 6

I caught the error in our log file and pasted in the forum. I can rule out "no such file" or "permission denied" because the files were actually there when I viewed the directory. It is also on our developement unix server where I have full access. I would almost gather the problem is the latter with the same name not sending back an acknowledgement to the API.

Thanks.

John

I'm sorry to labour on this, but when you say you received it from the API, what exactly do you mean? Did you catch an exception or did you copy and paste the stacktrace out of a log file?

The method in which the error originates throws 4 different exceptions so knowing the exception type and message would be really helpful. Two of them relate to standard error messages received from the server (e.g. "no such file" or "permission denied"), and the other two relate to probable failures in the SSH comms. Unfortunately the line-number doesn't help me to differentiate - probably because the source code has changed since your version.

Incidentally, if you did pass in the same name or a null, then it wouldn't be surprising to me if the server did complain about that.

- Hans (EDT)

Answer 7

A colleague just pointed out that some problems regarding permissions have been fixed in the latest version. Could you please download that one and see if it performs more as you expect?

- Hans (EDT)