Opened 8 years ago

Last modified 12 days ago

#7739 reopened Feature request

cannot connect to sftp server - "Too many authentication failures for user"

Reported by: John Owned by:
Priority: high Component: FileZilla Client
Keywords: sftp, too-many-authentication-failures Cc:
Component version: Operating system type: Linux
Operating system version: Arch Linux x86_64

Description (last modified by Alexander Schuch)

Filezilla 3.5.1 cannot connect to sftp servers with either key based or password based methods. Logs with debuging/verbose=3 attached.

I have verified that this is not a function of my system by repeating on an independent box with the same results. As well, I am pretty sure that nothing is wrong with the server because I used "sftp -P 34451 facade@mars" from a shell and connect just fine. As well, using gftp, I am able to connect. The Host OS is Archlinux x86_64 which is up-to-date (Arch is a rolling release).

Attachments (2)

key_based.log (1.7 KB) - added by John 8 years ago.
key-based log
password_based.log (1.7 KB) - added by John 8 years ago.
password based log

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by John

Attachment: key_based.log added

key-based log

Changed 8 years ago by John

Attachment: password_based.log added

password based log

comment:1 Changed 8 years ago by John

Resolution: fixed
Status: newclosed

I got it! Turns out that ~/.ssh/config was messing up FileZilla. I dunno why all of a sudden because I have been using my system with this config file for years. This file is formated like this:

Host github.com
  User facade
  IdentityFile /home/facade/.ssh/id_rsa_github_dot_com

Host mars
  User facade
  IdentityFile /home/facade/.ssh/id_rsa_mars

Host phobos
  User facade
  IdentityFile /home/facade/.ssh/id_rsa_phobos

Host deimos
  User facade
  IdentityFile /home/facade/.ssh/id_rsa_deimos

I read on the github wiki that one needs this file when dealing with multiple keys. Anyway, if I move ~/.ssh/config out of ~/.ssh, FileZilla works again. Apparently the github wiki is incorrect. I checked, and I am able to push to github without this file. Further, I am able to connect to all my hosts without this file. Problem solved - sorry for the false alarm.

comment:2 Changed 8 years ago by John

Resolution: fixed
Status: closedreopened

Wait... this is NOT resolved. After a reboot I am back to the same behavior even omitting the ~/.ssh/config file!

comment:3 Changed 8 years ago by John

I think the problem is that filezilla only tries 3 keys but I have 5 in my ~/.ssh.

Trace:   Trying Pageant key #0
Trace:   Server refused public key
Trace:   Trying Pageant key #1
Trace:   Server refused public key
Trace:   Trying Pageant key #2
Trace:   Received disconnect message (protocol error)
Trace:   Disconnection message text: Too many authentication failures for facade
Trace:   Server sent disconnect message
Trace:   type 2 (protocol error):
Trace:   "Too many authentication failures for facade"
Error:   Server sent disconnect message
Error:   type 2 (protocol error):
Error:   "Too many authentication failures for facade"
Trace:   CSftpControlSocket::ResetOperation(66)
Trace:   CControlSocket::ResetOperation(66)
Error:   Could not connect to server
Status:   Waiting to retry...

If I move all but the one that I need to another dir, filezilla connects as expected.

comment:4 Changed 8 years ago by John

Type: Bug reportFeature request

I think having filezilla read ~/.ssh/config to know which key to use would be needed here. Why just try all keys?

comment:5 Changed 7 years ago by Daniel Quinn

+1 for having Filezilla parse ~/.ssh/config rather than just trying all the keys. The current behaviour breaks the convention of every other ssh-based connection and led me to believe I'd configured Filezilla wrong for weeks.

For now, a decent work around for people not wanting to kill their ssh agent, this works for me:

$ SSH_AUTH_SOCK=""; filezilla

Obviously this only disables the use of the agent, rather than teaching Filezilla how to work with it, but it gets the job done.

comment:6 Changed 6 years ago by Alexander Schuch

Priority: criticalhigh
Resolution: duplicate
Status: reopenedclosed

This is a duplicate of #5480.

comment:7 Changed 4 years ago by Alexander Schuch

Description: modified (diff)
Keywords: too-many-authentication-failures added

comment:8 Changed 8 months ago by klam0

Resolution: duplicate
Status: closedreopened

Please let me to disagree. I have more than 100 keys, do you think it's OK to bombard every single server I connect to with hundreds of keys when every single one of them are going to fail?

It is inconvenient, it is also a privacy issue: I don't want FileZilla to send every public key I own to anywhere I connect to (that's why I use "IdentitiesOnly yes" in SSH config, and create a separate keypair for every server I access, or sometimes just use a password w/o a key).

This IS a bug, at least please leave the issue open so some interested people who can code can see it and maybe solve the issue.

Thank you.

Edit: I meant to reopen #8232 but wrote the text in a wrong tab, sorry.

Last edited 8 months ago by klam0 (previous) (diff)

comment:9 in reply to:  8 Changed 12 days ago by AG3

100% agree with this.

AG3

Replying to klam0:

Please let me to disagree. I have more than 100 keys, do you think it's OK to bombard every single server I connect to with hundreds of keys when every single one of them are going to fail?

It is inconvenient, it is also a privacy issue: I don't want FileZilla to send every public key I own to anywhere I connect to (that's why I use "IdentitiesOnly yes" in SSH config, and create a separate keypair for every server I access, or sometimes just use a password w/o a key).

This IS a bug, at least please leave the issue open so some interested people who can code can see it and maybe solve the issue.

Thank you.

Edit: I meant to reopen #8232 but wrote the text in a wrong tab, sorry.

Note: See TracTickets for help on using tickets.