Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
1.1k views
in Java FTP by (160 points)
When testing the EDT client via SFTP with a SFTP Server, we can observe in the SFTP Server logs that in case the client has wrong credentials (ex: wrong pasword), it actually makes two login attempts; is this a default value stored somewhere ? is there any way (configuration / API) by which we configure this login attempts count ?

1 Answer

0 votes
by (51.6k points)
It may be that it's trying first with regular password authentication and then again using the same password with KBI (KeyBoard Interactive).  What do the logs say?
by (160 points)
INFO [...com.enterprisedt.DhFixedGroup] 5 Mar 2019 10:33:28.595 : Starting client side key exchange.
INFO 5 Mar 2019 10:33:28.764 : Authentication PARTIAL - trying alternative method via keyboard-interactive authentication (user='user')
by (162k points)
Yes, that's what it is doing. It uses KBI as a fallback attempt if password authentication fails.
by (160 points)
Ok, but is there a way to disable the KBI fallback via API ? or is it the server that forces the client to try the fallback ?
by (162k points)
No, it's automatic (because often servers have password auth disabled and KBI has to be used).
by (160 points)
This how the code from SCPClient class looks like:

 public void setAuthentication(String userName, String password, PasswordChanger pwdChanger)
    throws FTPException
  {
    checkConnection(false);
    PasswordAuthenticationClient localPasswordAuthenticationClient = new PasswordAuthenticationClient();
    localPasswordAuthenticationClient.setUsername(userName);
    localPasswordAuthenticationClient.setPassword(password);
    localPasswordAuthenticationClient.setPasswordChangePrompt(pwdChanger);
    this.authenticator = localPasswordAuthenticationClient;
    
    KBIAuthenticationClient localKBIAuthenticationClient = new KBIAuthenticationClient();
    localKBIAuthenticationClient.setUsername(userName);
    SSHAuthPrompt[] arrayOfSSHAuthPrompt = new SSHAuthPrompt[1];
    arrayOfSSHAuthPrompt[0] = new SSHPasswordPrompt(password);
    localKBIAuthenticationClient.setKBIRequestHandler(new b(arrayOfSSHAuthPrompt));
    this.retryAuthenticator = localKBIAuthenticationClient;
  }

So retry is indeed automatically enabled; maybe this is documented in the guides and I've missed that part (the API specs, however, don't mention this behavior); in my opinion it may be useful to also have a "password only" without the fallback: in our case, using EDT, we've built a CLI ftp client tool to connect to a Apache Mina Core SFTP server (also under our control), so we want the FTP client to only use the password with which it has been configured (no interactive "enter password", even if it is CLI), without asking any other arguments in the CLI.
by (51.6k points)
I agree that it's a good idea to add a flag that would disable the KBI fallback, but it would take some time before we'd be able to get you a patch for that.  It looks like you've got the source-code, so why don't you just extend SSHFTPClient and override setAuthentication(String,String,PasswordChanger) like this:

public void setAuthentication(String userName, String password, PasswordChanger pwdChanger)
    throws FTPException
{
    super(userName, password, pwdChanger);
    retryAuthenticator = null;
}
by (160 points)
Thanks for the suggestion, although we don't have the source code (I've used a decompiler to find out the code), that does not prevent us from extending the framework as advised. The only issue that remains is that, we ship our product (including FTP client) to lots of automotive customers that have lots of FTP partners of their own, so a multitude of SFTP servers exist out there, not just our own, and the current fallback mechanism is used on a large scale; long story short: if we globally disable the fallback mechanism, this will break FTP clients that happened to connect to SFTP servers that only support KBI; so we will apply this suggestion only on a "per partner" basis, in order not to disrupt backwards compatibility.
by (51.6k points)
Yes that sounds wise.

Categories

...