Getting Authentication method not supported error

0 votes
asked Nov 2, 2013 by mharges (130 points)
edited Nov 5, 2013

Hi -

I'm evaluating the current trial version of RebexSftp and I'm getting an exception that states "Authentication method not supported. Supported methods: 'publickey'"

I'm using SmartFTP to connect to the same site using just username/password so I'm sure that publickey isn't the only way to connect. Looking over the documentation I see that the Sftp object Connect method has an overload that supports threee parameters: serverName, serverPort and parameters where it appears that I can specify the authentication method of 'Password'.

Unfortunately that overload of the Connect method does not appear to be available in the trial version. Intellisense only shows two overloads: serverName and serverName plus serverPort.

What's the correct way to connect with username/password?

Applies to: Rebex SFTP

1 Answer

+1 vote
answered Nov 4, 2013 by Jan Sotola (17,310 points)
edited Nov 5, 2013

The Connect(hostname, port, parameters) overload is deprecated. It is not available in itellisense, but you can still use it. The correct (not deprecated) way is to set the parameters using the Settings property:

sftp.Settings.SshParameters = parameters;
sftp.Connect(serverHost, serverPort);

However, setting the AuthenticationMethods parameter would not help, the component supports Any method by default and setting the AuthenticationMethods is rather used to reduce the set of allowed methods.

If you are reciving the message Authentication method not supported. Supported methods: 'publickey', there is something wrong either in the server or in the component. Could you, please, create a Debug communication log and post it here or send it to support@rebex.net. We would try to find out, what is wrong in the authentication process.

commented Nov 4, 2013 by mharges (130 points)
edited Nov 4, 2013

Jan - thanks for the reply. I added the code to generate the log as you suggested and now the connect succeeds. I need to re-run without the log to to confirm that the problem is truly resolved.

commented Nov 5, 2013 by mharges (130 points)
edited Nov 5, 2013

Jan - the error has re-appeared. I've emailed both success and failure logs to the support address.

commented Nov 5, 2013 by Lukas Pokorny (121,750 points)
edited Nov 5, 2013

Thanks for the logs! It indeed looks very strange - everything seems to be the same, but it doesn't seem to work all the time. However, since the actual authentication packets are very simple (try using LogLevel.Verbose intead of LogLevel.Debug to see), I'm afraid the problem might be unrelated to client code... Do you have access to the server? Is there anything related to the error in its log? That might make it possible to tell what is going on.

...