Tag Archives: linux

Received disconnect from: Too many authentication failures for ubuntu

Short answer: Add IdentitiesOnly yes to your .ssh/config file.

Long answer:

I was receiving the error message “Received disconnect from X.X.X.X: 2: Too many authentication failures for ubuntu” while trying to login to some of my servers. Tried logging into various other servers and some worked and some didn’t. I was using public key authentication and I know the keys were correct so I tried logging into the failing servers from other machines and they all worked, same keys, so the keys were all good and the server was working just fine.

Time to ssh -vvv to see what errors were occuring. At the end of the output I was seeing a lot of this:

debug1: Offering RSA public key: wes@desktop
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: wes@desktop
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey

Ok, so it looks like my public keys are failing. I’m using my .ssh/config file to assign specific IdentityFiles to Hosts, perhaps that was failing so I tried passing the path to the IdentityFile directly via ssh -i. Still nothing, it still is passing several publickeys and failing on all of them. My servers all have the default setting in the sshd_config for MaxAuthTries set to 6, increasing that helps but that’s not the direction I want to change that value and I don’t want to do that across dozens of servers and this appears to be a client side problem.

Next up, I did a little googling around and ran ssh-add -L and see that ssh-agent has cached 6 public keys. ssh automatically tries those 6 keys first always and then tries the ones you specify on command line or in your config file. That’s not really super cool, I guess it assumes you are using the same key or it needs a default to look for and try. One option was to run ssh-add -D, that wasn’t really working and doesn’t directly solve the problem. Instead I read the manual, what a novel idea, and found the setting IdentitiesOnly and set it to yes, what this does is instead of checking ssh-agent for cached keys it will use your defined identity file only… MUCH better! So, just add IdentitiesOnly yes to your .ssh/config file and you are set. Or put this in the /etc/ssh/ssh_config file for the entire system.

Use curl to upload files and post other data

This should’ve been more obvious to me but it did take a few minutes of playing around and reading the manual to get this right. I wanted to post data to a api using curl and one of the items was a file upload and another was a simple field/value.

To upload a file via curl:

curl -X POST -F "image=@profile.jpg" http://api.example.com/profile

In php this will give you the profile.jpg in the $_FILES[‘image’], now to add additional field values you just add additional -F arguments like this:

curl -X POST -F "image=@profile.jpg" -F "phone=1234567890" http://api.example.com/profile

Escape SSH Sessions

I’ve seen a few blog posts around outlining this but I always seem to forget and then take a few minutes searching for it again so I thought I’d post it here just so I can always find it again.

When you have an ssh session open in your terminal or in screen and you need to hop out of it or you need to kill a hung session you can do it with the ~ hotkey.

*Press return once first before hitting the hotkey to start a fresh entry, even if you enter something and press backspace to clear it you still need to hit return once first.

Kill Session:


Suspend Session to Background:




sudo: unable to resolve host example.com

There was a nagging issue I had with a dev server where any user that used sudo it would produce the error:

sudo: unable to resolve host example.com

The probelm: the hostname had an incorrect line ending in the file /etc/hostname.

The solution: reset the fileformat for the file back to unix. I did this with vim.

sudo vi /etc/hostname
:set ff=unix

automysqlbackup/mysqldump of Views on a MySQL Replication/Slave machine

Today an error appeared in my inbox from automysqlbackup indicating there was an issue with the backups being run from a slave machine that is used strictly for running backups.

mysqldump: Got error: 1045: Access denied for user 'backup'@'localhost' (using password: YES) when using LOCK TABLES

Unfortunately this was not overly useful.

I tracked down the particular database that was causing problems and received a new error message that was getting a lot more useful:

mysqldump: Couldn't execute 'show create table `REPORT`': SHOW VIEW command denied to user 'backup'@'localhost' for table 'REPORT' (1142)

I’m no expert but what this is roughly saying is that the ‘backup’ user @ ‘localhost’ does not have the ‘SHOW VIEW’ privileges and because ‘REPORT’ is a view and not an actual table and my backup user typically only has ‘SELECT’ this is where we were failing. Seems simple enough assign the user the correct privileges and we should be good to go.

Not so fast. I ran into one more error attempting to access this view:

mysqldump: Got error: 1449: The user specified as a definer('root'@'%') does not exist

Once again I’m far from an export on this but my understanding is that the view was created or defined by a particular user known as the definer and because this is a slave machine the user that created the view was only on the master server (as the mysql db is not replicated over) and not on the slave machine therefore the view was inaccessible.

I created the correct user (exact same username @ hostname) on the slave machine and now our backup user with correct privileges was able to read the view and perform the backup as expected.