Too Many Authentication Failures for Root in Filezilla

Too Many Authentication Failures for Root in Filezilla

Too Many Authentication Failures for Root in Filezilla

PROBLEM: “Too many authentication failures for root” in Filezilla. Keeps dropping SFTP connection.

SOLUTION: Delete private keys from Filezilla/settings. Install and configure keychain to manage ssh-agent and ssh private keys and passphrases.

Tonight started out pretty normal… I created a new Droplet for a client. Configured all of the packages we need, took a snapshot and transferred it to my client’s DigiatOcean account. No problems connecting over SSH with the shell. The problems began when I tried connecting via SFTP with Filezilla — a basic requirement.

I’m embarrassed to admit how long I spent rebuilding a Droplet, that should have been up and running in less than an hour. Sometimes, the answer is so obvious, that you just can’t see it. The same error “too many authentication failures” over and over again. Then it just keeps dropping the SFTP connection. The good news is, I wasted nearly a whole evening so you don’t have to.

Did I do anything different with the setup of this Droplet that might (but shouldn’t) have affected SFTP? Ah-HA! I enabled IPv6! So I destroyed my hard work and went to task rebuilding the server again, this time without IPv6 support… Damnit! Same problem! Did I remember to configure UFW to allow traffic on all ports from my IP address? Check. That’s not it either… Hmmmm, maybe there’s some garbage in my router/modem that’s fucking with the ports… Restarted both. Tried to reconnect. Same problem…

Things are really getting desperate now… I’m totally disgusted! WTF? Time for a Starbucks. Thank you baby Jesus for the new Starbucks drive-thru in Hollywood!

OK… Now, that I’ve had a Starbucks, what is this “too many authentication failures” error about? If you examine the dialog while Filezilla is attempting to connect, you see that it tries EVERY private key you have saved in Filezilla until it reaches the correct one for this server. By the time it does, it’s already reached the threshold set for too many authentication failures.

fz-too-may-auth-failuresThat’s like trying every key on your key-ring until you find the right one, but before you can unlock the door, it sets off an alarm for trying too many different keys. Good for security, but really inconvenient. Of course, you could just change the maximum number of failed auth attempts on your remote server. But that compromises your security policy.

The way Filezilla handles private keys isn’t very efficient either. Why isn’t it possible to define the private key associated with a host in the host manager? So it knows exactly which key to use every time – like using those plastic key wrappers to identify each key.

If your private keys are protected with a passphrase, Filezilla still doesn’t know how to deal with that, so you end up with another authentication error. And letting Filezilla convert your keys and remove the passphrase, defeats the purpose of protecting your keys.

Before we begin, if you need help creating your SSH keys, SSH Essentials: Working with SSH Servers, Clients, and Keys at DigitalOcean is recommended reading. For more technical details on SSH, ElectricMonk has a comprehensive article.

Screenshot from 2015-05-19 17:05:21What’s surprising, is how little info I could find specifically related to managing passphrase protected private keys in FileZilla. A lot of info indirectly related to the subject, like password-less login, using ssh-agent and some sketchy info about SSH_AUTH_SOCK. And then, there’s the ambiguous FileZilla message about setting the SSH_AUTH_SOCK environment variable.

This method of installing Keychain and letting it manage ssh-agent and SSH_AUTH_SOCK solves several problems.

  • Multiple ssh-agents running
  • Maintaining SSH private key passphrase integrity
  • Sharing the info with Filezilla
  • Session Persistence (until reboot)

Install keychain:

Add the text below in ~/.bashrc (replacing the example private keys with your actual keys, separated with spaces on a single line):


Assuming that your keys are located in the ~/.ssh directory. Keychain expects the public key associated with each private key to be saved locally in the same directory or it will throw errors.

If you followed this tutorial last week and have your .ssh/config file set up, then you can use the friendly names you gave each host, to easily ssh into your remote servers.

For instance, I use the following to connect to my server:

Locate and copy the public key:

NOTE: if you created all of your SSH key pairs on the computer you’re configuring, you can skip ahead to FileZilla.

Highlight everything beginning with: “ssh-rsa” (without the quotes) to the last character in your public key (possibly your email address). Everything up to, but not including your username@your-server.

close your ssh session with:

Then paste the public key you just copied into a file on your local host. If the private  key is called example1_rsa in your .ssh directory then create a file with the same name ending with the “.pub” extension.:

Repeat steps above for every private key and server you wish to use with Filezilla.

Open the FileZilla/site manager:

Enter the following in the Filezilla Site Manager:

  • Host (
  • Protocol: SFTP – SSH File Transfer Protocol
  • Login Type: Normal
  • User: root (possibly ubuntu or ec2-user on AWS — this must be the actual username you use to SSH in to your server)
  • Password: no password (leave blank since we’re using a private key to authenticate)

Restart your computer:

Each time you login, you will see “Keychain error found when loading your /home/[$USER]/.profile:” Don’t stress, this nag will resolve itself when you open a terminal and supply the missing passphrases associated with those private SSH keys. Click “OK” to finish logging in.

Open a terminal window:

You will be greeted with a prompt to enter the passphrase for each protected private key (you will need to supply these at every reboot).

Open Filezilla:

The first time you connect to a site with a passphrase protected SSH priavte key, Keychain will prompt you to enter the passphrase. Enter the passphrase for that key (not your Linux user password). If you check the button to remember the passphrase before hitting the “Unlock” button, you won’t need to supply the passphrases manually to Filezilla again.


You will still need to supply the passphrases for each protected key at every reboot, but Filezilla will get the passphrases from Keychain.

Final thoughts:

Haven’t figured out what’s causing it, but I’ve noticed occasional flakiness in authentication failures (in FileZilla) still. The fix for me has been to flush my keys from memory. This is still the best method I’ve found for managing multiple passphrase protected keys with FileZilla on Linux.

To flush your keys:

  1. Log out of your desktop session.
  2. Log back in.
  3. Open terminal and reauthorize your keys.
  4. Open FileZilla and you should be fine.