FileZilla Forums

Filezilla ignores the Site Manager settings and never sends the user name and password entered in Site Manager. Instead, it sends unrelated keys residing in my .ssh directory to the server even though I have selected "Logon Type: Normal" with a User Name and Password entered. I DO NOT have "Logon Type: Key File" selected. The server counts each key sent by Filezilla as an authentication attempt and reaches the server's maximum number of attempts before returning the Error: "Too many authentication failures for (user)" "Could not connect to server".

Thus, I cannot log in to my sites. I have created a config file in my .ssh directory and added the lines "host (domainname)" & "PubkeyAuthentication=no". This resolved the identical error I was receiving when trying to log in to these sites with SFTP in a terminal but it appears as though Filezilla ignores the preferences in the .ssh/config file even though it is picking up the keys in the .ssh directory.

How do I force Filezilla to ignore the unrelated SSH keys and use ONLY the User Name and Password as entered in the Site Manager entry?

Just don't load all your keys into your system's SSH agent.

Note that, unless you rely on agent forwarding, using more than one private key with SSH does not offer any additional security, it just makes things more complicated.

botg wrote: ↑

2018-07-11 20:18

Just don't load all your keys into your system's SSH agent.

Note that, unless you rely on agent forwarding, using more than one private key with SSH does not offer any additional security, it just makes things more complicated.

How is that an appropriate solution for an app that doesn't respect it's own settings? If I select NORMAL Logon Type, not KEY FILE, why is it even passing keys in the first place?

I have keys for several servers that are accessed in cron jobs on a daily basis, but I also need to access a half a dozen other servers infrequently enough that keys are not really necessary. I'm not going to delete the keys and cause the associated cron jobs to fail just because Filezilla doesn't work as it should.

For SFTP it is normal to first try any keys provided by the system's SSH agent before falling back to password authentication.

Is there a way to pass the -o flag in Filezilla?

The following command works in the terminal

ssh -o PubkeyAuthentication=no username@12.34.56.78

By using the -o flag, the connection will disregard public key authentication all together and go straight to user/pass login.

No.

Might be a useful feature request for a future version. It seems there are quite a few people running into the same problem.

Hello,

I ran into the same problem and it took me about an hour to fix it. I am currently setting up my development environment on Ubuntu, moving away from my Windows machine. However, there, with exact same connection settings using FileZilla, I could connect to all of my customer's servers using SFTP. Using the same settings and credentials (user/password == normal auth) I only received the message "connection closed". I found the debug log level setting and changed it to verbose, logging "Using Pageant" and "trying pageant key #0" though I didn't specify any key to be used on any of the connections. Killing ssh-agent -k didn't help. However I then renamed my ~/.ssh directory so my ssh keys would be inaccessible. Only then FileZilla managed to connect successfully. Even though right thereafter I restored my ~/.ssh directory FileZilla connects successfully now on all following attempts, even after restarting FileZilla.

I cannot imagine this to be "works as intended". The settings in the connection manager clearly imply that no keys would be used. Without changed debug log levels there would be no clue at all to what is going on.
I cannot imagine that this is a rare case but it rather is a major inconvenience in the otherwise seemingly flawless FileZilla.

Hope this issue will be resolved in some way or another.
Hope this post may help others stumbling over the same problems!
Best,
Alex

The problem is faulty servers closing the connection after the first unrecognized key. A proper SSH server keeps the connection alive so that the client can continue with further keys or even other authentication mechanisms.

This is a bit over my head, but I think I am having this problem. I am not even sure if I am using the right words to describe the problem, so bare with me.

I am using Filezilla to login to a SFTP server hosted by WPEngine.com.

I am trying to use just a simple a password, but Filezilla keeps opening a keyfile that I only used in Putty and Bitvise.

What is weird is that I never used a key file in Filezilla before, so I have no idea why it is using keys I only used in other apps. How did it even know?

I have used Normal, Ask For Password, and Interactive, and it always goes to the Key File no matter what. I uninstalled. Deleted directories and cleared regedit. Still I can't get it to stop.

Anyway, I think Filezilla tries to use the key file as a password, and I get kicked out. I never get a chance to enter in my own actual password.

Filezilla just always worked for years. I think this problem started after I installed and started using Putty and Bitvise for DigitalOcean. I think it may have broke because of the update. Not sure.

I use to use Filezilla for all SFTP stuff. Now it is broken and I can't fix it.

This is like saving a document in Word, and now Photoshop only opens that Word doc no matter what JPEG or PNG or PSD file you click on.

In SFTP, key-based authentication trumps password-based authentication. All globally defined keys (either in FileZilla global settings or in the system's SSH agent) are always tried before falling back to the legacy password-based authentication. This is working as intended. What is not working as intended is SFTP servers force-closing the connection before all authentication possibilities have been exhausted. In FileZilla, using "key file" authentication in the Site Manager is an explicit method supplying a key. Even if not explicitly using key file authentication, all globally defined keys are implicitly sent as part of the authentication process. Password-based authentication comes last, as fallback.

Filezilla just always worked for years. I think this problem started after I installed and started using Putty and Bitvise for DigitalOcean. I think it may have broke because of the update. Not sure.

At least in Windows, there is no SSH system agent by default. There simply weren't any keys to try. By installing PuTTY, you introduced an SSH key agent (Pageant). Pageant keys are global and thus implicitly tried at login.

The RFC defining SSH recommends a limit of 20 authentication attempts before closing the connection, which is plenty even in the presence of a dozen keyfiles.

Reality is probably more like three to five.

I wanna do what I wanna do. Not what someone thinks I should do.

I don't want my app going through a bunch of keys I know for a fact are not going to work, before it gets around to trying the password I know will work right off the bat.

The app is acting like a kid with OCD trying to turn off a light.

I guess that means I will choose to use another app.

CoreFTP gets the job done, so problem solved.

I used Filezilla for years, but time to go. I gave it a chance, but it don't wanna listen and I don't have the time.

Well, blame the makers of the SSH/SFTP protocol, then. FileZilla is simply following the specs (rules).