SFTP: Authentication failed

SmartFTP try to use FTP port (21), but I choose SFTP! Please, fix this bug.

[11:09:00] Resolving host name "myhostIP"
[11:09:00] Connecting to myhostIP Port: 21
[11:09:01] Client closed the connection.
[11:09:01] Connect failed. Waiting to retry (30s)...

Set the port to 22 in the settings and try again.

I think it must set automatically

Set port to 22, but other problem:

[19:40:49] SmartFTP v3.0.1012.0
[19:40:54] Resolving host name "MyIPhost"
[19:40:54] Connecting to MyIPhost Port: 22
[19:40:54] Starting SSH session. Remote Id: "SSH-2.0-OpenSSH_4.3p2 Debian-9"
[19:40:54] Initiating key exchange.
[19:40:54] Computing session key.
[19:40:54] Key Exchange Algorithm: diffie-hellman-group-exchange-sha1
[19:40:54] Key exchange completed.
[19:40:54] Host Key Algorithm: ssh-rsa
[19:40:54] Client to Server Encryption: aes256-ctr
[19:40:54] Server to Client Encryption: aes256-ctr
[19:40:54] Session HMAC: hmac-sha1
[19:40:54] Client to Server Compression: none
[19:40:54] Server to Client Compression: none
[19:40:54] Authentication request. Method: "none"
[19:40:54] Server supported authentications: publickey,password
[19:40:54] Authentication request. Method: "password"
[19:40:54] User authentication failed.
[19:40:54] Client closed the connection.
[19:40:54] Connect failed. Waiting to retry (30s)...

Password is correct. In WinSCP all is working correctly.

Hello ..

SmartFTP has been tested with OpenSSH and it is working fine. The username/password entered is probably incorrect.

Does your username/password contain any special characters?

Regards,
SmartFTP

Yes, I have > in password

Tested with
[03:31:53] Starting SSH session. Remote Id: "SSH-2.0-OpenSSH_4.6p1 Debian-3"

and works as expected.

Regards,
Mat

Test again in ver. 3.0.1012.6, same problem:

[00:45:32] SmartFTP v3.0.1012.6
[00:45:36] Resolving host name "XX.XX.XX.XX"
[00:45:36] Connecting to XX.XX.XX.XX Port: 22
[00:45:36] Starting SSH session. Remote Id: "SSH-2.0-OpenSSH_4.3p2 Debian-9"
[00:45:36] Initiating key exchange.
[00:45:38] Computing session key.
[00:45:38] Key Exchange Algorithm: diffie-hellman-group-exchange-sha1
[00:45:39] Key exchange completed.
[00:45:39] Host Key Algorithm: ssh-rsa
[00:45:39] Client to Server Encryption: aes256-ctr
[00:45:39] Server to Client Encryption: aes256-ctr
[00:45:39] Session HMAC: hmac-sha1
[00:45:39] Client to Server Compression: none
[00:45:39] Server to Client Compression: none
[00:45:39] Authentication request. Method: "none"
[00:45:39] Server supported authentications: publickey,password
[00:45:39] Authentication request. Method: "password"
[00:45:39] User authentication failed.
[00:45:39] Client closed the connection.
[00:45:39] Connect failed. Waiting to retry (30s)...

In WinSCP connected succesfully. Please, try again to locate bug. How can I help you to fix this bug?

Update the server to the latest OpenSSH version and try again. I do not believe there is a bug with SmartFTP.

Test again. In WinSCP all is working OK! I connected. Test new version of SmartFTP 3.0.1012.15 - again same error

[00:57:14] SmartFTP v3.0.1012.15
[00:57:21] Resolving host name "x.x.x.x"
[00:57:21] Connecting to x.x.x.x Port: 22
[00:57:21] Starting SSH session. Remote Id: "SSH-2.0-OpenSSH_4.3p2 Debian-9"
[00:57:21] Initiating key exchange.
[00:57:23] Computing session key.
[00:57:23] Key Exchange Algorithm: diffie-hellman-group-exchange-sha1
[00:57:23] Key exchange completed.
[00:57:23] Host Key Algorithm: ssh-rsa
[00:57:23] Client to Server Encryption: aes256-ctr
[00:57:23] Server to Client Encryption: aes256-ctr
[00:57:23] Session HMAC: hmac-sha1
[00:57:23] Client to Server Compression: none
[00:57:23] Server to Client Compression: none
[00:57:23] Authentication request. Method: "none"
[00:57:23] Server supported authentications: publickey,password
[00:57:23] Authentication request. Method: "password"
[00:57:23] User authentication failed.
[00:57:23] Client closed the connection.
[00:57:24] Connect failed. Waiting to retry (30s)...

I have exactly the same problem. Without a special character in my password, SFTP over SSH is working fine. By having a "*" in my password, the error described by allmoney.ws occurs. I tried to use different character sets but that didn't help. So I think this is definitely a bug in SmartFTP, I think. By the way, I really do appreciate the integration of an SFTP client into SmartFTP, great work!

Hi
I have the same problem. Is x considered a special character or an alphabet? I have it in both my username and password.
Thanks

An "x" is not considered a special character.

hi
then why do i get the user authentication failed error?

For me the process is like this:

Authentication request. Method: "password"
Authentication request. Method: "keyboard-interactive"

What is keyboard-interactive login? I have this as my favorite, and I use that favorite to login. So my username password is saved in the favorite.

thanks

It's becaues the username/password you have entered is wrong or there is a problem on the server side.

It's becaues the username/password you have entered is wrong or there is a problem on the server side.
Hi
No, because I checked with the guy who gives out the username/password, and it is correct, as I checked my favorite, and there also it is correct.
What could be the problem on serverside?
thanks

There is no error on the server side.

When the password is input into the Favorite, the connection is successful, however if it's left out in the Favorite and you get prompted for it during a connection, authentication fails regardless of what you input.

Annhiliator: Yep it's a bug when the session username/password are used. We will provide a fix in the next days.

Thank you for reporting.

This bug has not been fixed. I have 3.1019.5 which is the latest and I cant access my root using a password with special characters. I can access it fine with special characters using WinSCP so its not the password and if I change the password to something with no special characters I can connect using SmartFTP fine.

Allosunshine: It's probably a bug on the server side. It doesn't interepret the UTF8 encoded password correctly. Upgrade to the latest OpenSSH version and try again.